Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tdevries@suse.de (Tom de Vries)
Cc: arnez@linux.ibm.com (Andreas Arnez),
	gdb-patches@sourceware.org,        tom@tromey.com (Tom Tromey)
Subject: Re: [PATCH] s390: Implement 'type_align' gdbarch method
Date: Fri, 30 Aug 2019 15:16:00 -0000	[thread overview]
Message-ID: <20190830151633.1AB17D802F0@oc3748833570.ibm.com> (raw)
In-Reply-To: <58a64dce-9855-c43b-43f9-f93fdd31ab73@suse.de> from "Tom de Vries" at Aug 27, 2019 01:29:22 PM

Tom de Vries wrote:

> in the "zSeries ELF Application Binary Interface Supplement" document I
> find long double listed with 16-byte size and alignment.
> 
> Likewise in the "IBM XL C/C++ for Linux on z Systems Optimization and
> Programming Guide".
> 
> So I wonder, is this patch hardcoding the assumptions of a single
> compiler implementation (gcc) in gdb, thereby possibly breaking
> functionality in gdb when debugging executables generated by other
> compilers?

This was an error in the original ABI document, unfortunately.
We are currently working on an updated ABI document that will
fix this (and several other errors).  Andreas should know the
current status of this update.

To my knowledge, every Linux on Z compiler in existance has
implemented the 8-byte alignment for long double.  (This is
certainly true for GCC and LLVM; I cannot check XL C since
this is no longer supported on Linux.)

There is in fact a good reason for having (at most) 8-byte
alignment for all standard types: the ABI only guarantees that
the incoming stack pointer is 8-byte aligned.  Having any larger
alignment requirement on a standard type would basically force
compilers to implement dynamic stack realignment.

(If I were to re-design the ABI from scratch today, that
would certainly be one of the things I'd do differently
-- but we are where we are.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2019-08-30 15:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 11:40 Andreas Arnez
2019-08-08 17:01 ` Tom Tromey
2019-08-09 18:32   ` Andreas Arnez
2019-08-27 11:29 ` Tom de Vries
2019-08-30 15:16   ` Ulrich Weigand [this message]
2019-08-30 15:42     ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190830151633.1AB17D802F0@oc3748833570.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=arnez@linux.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox