SHT_UNWIND instead of SHT_X86_64_UNWIND?

[Ali Bahrami]

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