This is the mail archive of the
mailing list for the GCC project.
Re: x32 psABI draft version 0.2
- From: Roland McGrath <roland at redhat dot com>
- To: "H. Peter Anvin" <hpa at zytor dot com>
- Cc: x32-abi at googlegroups dot com, "H.J. Lu" <hjl dot tools at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 16 Feb 2011 12:29:20 -0800 (PST)
- Subject: Re: x32 psABI draft version 0.2
- References: <AANLkTindyH6koj0dCn1nxU9Cu3XUtg3XfvTnt_EWD13Q@mail.gmail.com> <4D5C2DD2.firstname.lastname@example.org>
> I'm wondering if we should define a section header flag (sh_flags)
> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> keying it to the ELF class...
I don't see what's wrong with paying attention to the class. IMHO sh_flags
only makes sense if you might ever mix x32 and normal x86_64 code together
in one link, in which case indeed neither class alone nor anything else
file-global is sufficient. If you don't do that, e_flags seems redundant
when it's already unambiguous from the class, but I suppose it doesn't hurt.
The only other complaint I imagine is the weirdo case of 32-bit systems
that deliver ELFCLASS64 core dump files so they can have a full 4GB of
memory as well as the thread state notes, where perhaps you'd want
something in the core file's headers (e.g. e_flags) to distinguish x32 from
x86_64. But it seems to me the actual core note layouts for x32 ought to
just be the x86_64 ones anyway, so it's hard to see really caring.