public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Ali Bahrami <Ali.Bahrami@Oracle.COM>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: x86-64-abi@googlegroups.com,
	Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>,
	gnu-gabi <gnu-gabi@sourceware.org>,
	binutils@sourceware.org
Subject: Re: SHT_UNWIND instead of SHT_X86_64_UNWIND?
Date: Fri, 13 Mar 2020 17:15:01 -0600	[thread overview]
Message-ID: <e8c83387-0966-10dd-c7ec-e55195fb9924@Oracle.COM> (raw)
In-Reply-To: <20200313223347.vvda5wduy3oiyx7u@google.com>

On 3/13/20 4:33 PM, Fāng-ruì Sòng wrote:
> At this point, I agree that the world is not going to be simplified.
> Toolchain has to continue to support SHT_X86_64_UNWIND.
> However, I think clarifying the canonical section type can guide future assembly files and toolchain support.

If the linkers have to support both, then I don't see much
to clarify. Either use is acceptable, and generates identical
valid objects.



> Now we have two choices for the canonical and recommended section type (SHT_PROGBITS should still be supported)
> 
> a) SHT_UNWIND
> 
>    We need a definition `#define SHT_UNWIND 0x70000001` in binutils and glibc/elf/elf.h

It can't be 0x70000001, because that number comes from
the platform specific range between SHT_LOPROC-SHT_HIPROC.
A generic SHT_UNWIND should be allocated from an unused
value in the generic ABI range (below SHT_LOOS).

However, doing that means having to add a lot of new
code to support this new value and interpret it as
an unwind section, layered on top of the existing
support for PROGBITS, and X86_64_UNWIND. It would
have been nice if we had started with SHT_UNWIND, but
it doesn't really seem worth it now.



> b) SHT_PROGBITS
> 
>    https://urldefense.com/v3/__https://reviews.llvm.org/D76151__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJan5ERENGQ$   Unfortunately this does not follow the ELF spirit. I won't object to
>    it if a) is excluded.

Modern Solaris doesn't really care whether you tag
these as UNWIND, or PROGBITS. It throws both into
the same section.

The resulting output section from our ld will be tagged
UNWIND on x86_64, and PROGBITS on other platforms,
as has been the case for years.


> "gcc produces UNWIND" - I think you meant SHT_PROGBITS. In the GCC
> repository, libphobos/libdruntime/core/sys/solaris/sys/elf_amd64.d is
> the only place where SHT_X86_64_UNWIND is mentioned.

I stand corrected. I just tried it on a Linux box, and
it is PROGBITS. On Solaris, gcc still sets it to UNWIND,
I think probably to avoid breaking us. Frankly, I like
seeing these tagged as UNWIND, since I believe in not
overloading PROGBITS, but it's just a personal taste,
not something others need to care about.


> https://urldefense.com/v3/__https://reviews.llvm.org/rL291107__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJan3IcUwjF$ As to section flags, at the very least SHF_GROUP and SHF_COMPRESSED should be ignored.
> SHF_MERGE may be ignored as well.

UNWIND sections are SHF_ALLOC, and SHF_COMPRESSED cannot
be applied to allocable sections, so I think you should
throw a "bad object" error, rather than ignore, so that
the producing program can be caught and fixed.

MERGE is a hint, the meaning of which depends on the section
type. I don't think it has a defined meaning for unwind, so
the normal behavior is to ignore it.

As to GROUP, it depends on the type of output object. For a
final object, group processing occurs before the output
object is created, and at that point, the GROUP flags
should have been removed. If you're producing a relocatable
output object though, you'd want to preserve the groups,
and have multiple sections.


>> Solaris 10 (ancient) isn't. Do you know Rainer Orth (cc;d)?
>> I'll suggest that you contact him offline and discuss it. Feel free
>> to cc me, and thanks.
> 
> I don't:) So it looks like https://urldefense.com/v3/__https://github.com/libffi/libffi/pull/546__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJanz-YOFPB$  can be further simplified by deleting SHF_WRITE support completely.

Don't let that stop you, he's very friendly. :-)

Rainer is the one person who knows where all the
gcc-on-Solaris bodies are buried, and can advise on
things like this. He and I work together all the time
on gcc support, and he's also got an interest in Clang,
so if you're working with him, I'll probably get pulled
in as needed.

- Ali

  reply	other threads:[~2020-03-13 23:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMe9rOo3Y=-xKzoP+tPu64yV5PGmCZZR=9LA3Ji9mDi25_Nqqw@mail.gmail.com>
     [not found] ` <20200313180946.aegom4ekzhjrywgo@google.com>
     [not found]   ` <4402d6f9-1804-9709-b276-17e8c2a5da17@Oracle.COM>
     [not found]     ` <CAFP8O3+zLNTDHyYbMVsvZbzVuPxe9jw08m+g1po6kGQk85AuAQ@mail.gmail.com>
     [not found]       ` <b8b055ae-0a66-2e82-9abb-76928e88c695@Oracle.COM>
2020-03-13 22:33         ` SHT_UNWIND instead of SHT_X86_64_UNWIND? (was: RFC: Usefulness of SHT_X86_64_UNWIND) Fāng-ruì Sòng
2020-03-13 23:15           ` Ali Bahrami [this message]
2020-03-16 14:47           ` Michael Matz
2020-03-16 18:51             ` Fāng-ruì Sòng

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=e8c83387-0966-10dd-c7ec-e55195fb9924@Oracle.COM \
    --to=ali.bahrami@oracle.com \
    --cc=binutils@sourceware.org \
    --cc=gnu-gabi@sourceware.org \
    --cc=maskray@google.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    --cc=x86-64-abi@googlegroups.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).