Original thread: https://groups.google.com/forum/#!topic/x86-64-abi/7sr4E6THl3g +gnu-gabi and binutils On 2020-03-13, Ali Bahrami wrote: >On 3/13/20 1:20 PM, Fāng-ruì Sòng wrote: >>GNU as uses SHT_PROGBITS for .eh_frame all the time, at least on >>non-Solaris. (I don't know how to test Solaris) >>clang integrated assembler uses SHT_X86_64_UNWIND for non-Solaris >>since 2015-11 (https://urldefense.com/v3/__https://reviews.llvm.org/rL252300__;!!GqivPVa7Brio!NfJGcj1nvZZaqv3GQplmmEnsoFvdbva-fe0qyEUJfeGtRHXUS8SLMPc6MyCJ-zrt$ ). >>So there are indeed some object files with SHT_X86_64_UNWIND. >>Fortunately, neither of GNU ld, gold, lld complains about mismatching >>section type (SHT_PROGBITS vs SHT_X86_64_UNWIND). >> >>So I don't think it is too late for removing SHT_X86_64_UNWIND and >>requiring .eh_frame to be SHT_PROGBITS. >> >>On the contrary, inventing SHT_UNWIND or SHT_GNU_UNWIND (generalizing >>SHT_PARISC_UNWIND/SHT_IA_64_UNWIND) and requiring every other >>architecture to adopt may be too late, >>but I think it may still be doable. > >Let me clarify: It's not that I think it's too late to make >either of these changes. It's that I think it's too late >to simplify the world by doing so. You can create and use >SHT_UNWIND, or you can eliminate SHT_X86_64_UNWIND, but >in either direction, we must continue to drag around the >obsolete forms, because existing objects contain them. As >such, there's no real simplification --- the linkers need to >continue handling both cases. Given that, I'd prefer for the >ABI to continue documenting it. > >The SHT_X86_64_UNWIND type (originally SHT_AMD64_UNWIND) arrived >with the 64-bit platform ABI, but the actual sections predate >x86_64, and are the same unwind sections that GNU had already >developed for other platforms, including 32-bit x86. OK, so it is unfortunate that x86-64 psABI says "The call frame information needed for unwinding the stack is output into one or more ELF sections of type SHT_X86_64_UNWIND." while there is no corresponding change made to the most widely assembler (GNU as). This sentence triggered https://reviews.llvm.org/rL252300 which made clang integrated assembler diverge. 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. 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 The canonical way to write .eh_frame in assembly (very rare, I've only seen instances in glibc/sysdeps/unix/sysv/linux/x86_64/sigaction.c , LuaJIT, libffi) will be: .section .eh_frame,"a",@unwind # Older non-x86 GNU as will emit "Warning: unrecognized section type", # but an assembler warning will not break the build. Newer readelf/llvm-readelf -S should print "UNWIND" instead of "X86_64_UNWIND". Alpha may not be happy due to SHT_ALPHA_DEBUG, but that is for ECOFF. MIPS may not be happy due to SHT_MIPS_MSYM. I don't know whether it is legacy cruft from today's view of point, but I don't see a problem because MIPS already does a lot of non-standard stuff (its .debug_* use SHT_MIPS_DWARF) b) SHT_PROGBITS https://reviews.llvm.org/D76151 Unfortunately this does not follow the ELF spirit. I won't object to it if a) is excluded. I maintain lld/ELF and LLVM binary utilities nowadays, and probably also LLVM MC (integrated assembler). I can made relevant changes. >As I understand it, the order of events was roughly: > > - GNU create unwind sections, based on the Itanium ABI, > to support C++. These were tagged SHT_PROGBITS, which > to me, was a missed opportunity to assign them a > proper section type, like SHT_UNWIND. > > - GNU essentially wrote the x86_64 platform ABI, which > codified a lot of things that were already done > on other platforms. I'm not sure how SHT_X86_64_UNWIND > got added, but it did, and this was also a missed > opportunity, again, to generalize it to all the other > platforms as SHT_UNWIND. > >Comparing section types is better than string matching, so >given a time machine, it would have been better to have >a generic section type from the start. However, without a >time machine, I'd leave well enough alone. Platform ABIs >aren't supposed to change very much, particularly when it >comes to removing things. It's a bit ugly, but it's done, and >it works. > >As to Solaris behavior, we see the same behavior as Linux >regarding the above. gcc produces UNWIND. as (really, the >people who write assembly code) usually produce PROGBITS. >And on non-x86_64, it's all PROGBITS. As a result, our >linker also knows to combine the two types. It took several >bugs to work all of that out, but it's been done for years. >Whether or not the platform ABI now removes SHT_X86_64_UNWIND >or not, we have to keep that code, to support old compilers, >and old objects. Hence, changing this seems a bit academic >now. When I said that we wouldn't change anything, whatever >the decision about the psABI, this is what I meant. "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. Thanks for sharing the history. >> Will be appreciated if you can tell me why SHF_WRITE is there:) >> (SHF_WRITE really made me sad while fixing >> https://urldefense.com/v3/__https://github.com/libffi/libffi/pull/546/files__;!!GqivPVa7Brio!NfJGcj1nvZZaqv3GQplmmEnsoFvdbva-fe0qyEUJfeGtRHXUS8SLMPc6M7K63TfA$ ) > >The Solaris ld follows the usual rules for combining >sections. Hence, readonly, and writable, sections with the >same name don't get combined, and you end up with 2 output >sections. At some point, 5-10 years ago, we started seeing >unwind sections with a mixture of SHF_WRITE and readonly, and >so, we were getting 2 different output sections, which for >unwind, is bad. On investigation, we determined that various gcc >supplied objects were inconsistent in this, but that that the >GNU linkers special cased them, merging them together without >regard for the WRITE bit. https://reviews.llvm.org/rL291107 As to section flags, at the very least SHF_GROUP and SHF_COMPRESSED should be ignored. SHF_MERGE may be ignored as well. As to section types, GNU as used the wrong section type for .init_array.nn until https://sourceware.org/bugzilla/show_bug.cgi?id=21287 (2017)... A linker script essentially matches sections by name. INPUT_SECTION_FLAGS exists but it is very rare and does not help with section types. So, in practice we have to diverge from the ELF spec. >As with the merging of PROGBITS and UNWIND, we followed suite with >a special case for combining readonly and writable UNWIND into a >single readonly output unwind section, and the issue went away. >This comment from our sources explains: > >I /* > * A final object (executable, shared, or kmod) is only supposed to have a > * single .eh_frame section, so that a .eh_frame_hdr section can be generated > * to describe it. If a mixture of read-only and read-write sections are > * encountered, the default behavior would be to produce two output sections. > * Although it is best to fix the compilers to not create .eh_frame sections > * with different flags, we are willing to merge such .eh_frame sections into > * a single read-write output section in order to work with existing tools. > * This is largely driven by the fact that the GNU link-editors appear to do > * such merging for all sections based on name. > */ > static Ld_ret > uniquify_ehframe(Ent_desc *enp, Ofl_desc *ofl, Os_family *nofp, Is_desc *nisp) > >We were a bit late to the party on this. I'll guess that your >code above dates from the window of time during which we weren't >merging these, and that some objects in the link were setting the >WRITE flag. Your adding that flag likely caused all the unwind >to land in one place. > >I think you might change that now. Solaris 11 is clean on this, while >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://github.com/libffi/libffi/pull/546 can be further simplified by deleting SHF_WRITE support completely.
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
Hello,
On Fri, 13 Mar 2020, Fāng-ruì Sòng via Gnu-gabi wrote:
> OK, so it is unfortunate that x86-64 psABI says "The call frame
> information needed for unwinding the stack is output into one or more
> ELF sections of type SHT_X86_64_UNWIND." while there is no corresponding
> change made to the most widely assembler (GNU as). This sentence
> triggered https://reviews.llvm.org/rL252300 which made clang integrated
> assembler diverge.
>
> 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.
I think realistically this is the only thing we can do for the x86-64
psABI: clarify and add acceptable section types, nothing of that will
simplify anything. So, I'd add SHT_PROGBITS as an additional acceptable
type for .eh_frame, but continue to recommend SHT_X86_64_UNWIND (because
that's in spirit), linkers will have to continue accepting both types for
the next umpteen years. So, that would document the de-facto state of the
psABI with a little nudging towards a better future (the recommendation).
Adding a whole new general section type (SHT_UNWIND) seems to accomplish
nothing than additional code for all existing psABIs. For _future_ psABIs
it might make sense to allocate and document an SHT_UNWIND now, but for
existing ones it doesn't seem to make much sense. (And for the general
type: would we then require this section type to be forever associated
with dwarf unwind info? What about ARM unwind info, that couldn't use
SHT_UNWIND then. Or would we leave the specific format of SHT_UNWIND to
the psABI, but still allow them to use that common section type despite
principal difference to other ABIs? All of those questions can be
answered in multiple ways with pros and cons for each, but they need to be
answered before a generic SHT_UNWIND could be introduced, at which point
it's even less obvious if we should even bother)
(FWIW, my personal opinion would be to document SHT_UNWIND in the gABI,
with psABI to clarify content; but to _not_ make use of it in existing
psABIs)
Ciao,
Michael.
P.S: I wish there would have been more implementations of the x86-64 psABI
right from the beginning ;-)
On 2020-03-16, Michael Matz wrote: >Hello, > >On Fri, 13 Mar 2020, Fāng-ruì Sòng via Gnu-gabi wrote: > >> OK, so it is unfortunate that x86-64 psABI says "The call frame >> information needed for unwinding the stack is output into one or more >> ELF sections of type SHT_X86_64_UNWIND." while there is no corresponding >> change made to the most widely assembler (GNU as). This sentence >> triggered https://reviews.llvm.org/rL252300 which made clang integrated >> assembler diverge. >> >> 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. > >I think realistically this is the only thing we can do for the x86-64 >psABI: clarify and add acceptable section types, nothing of that will >simplify anything. So, I'd add SHT_PROGBITS as an additional acceptable >type for .eh_frame, but continue to recommend SHT_X86_64_UNWIND (because >that's in spirit), linkers will have to continue accepting both types for >the next umpteen years. So, that would document the de-facto state of the >psABI with a little nudging towards a better future (the recommendation). +1 for clarifying that SHT_PROBITS .eh_frame is acceptable. SHT_X86_64_UNWIND is still the recommended type. I'll update my https://reviews.llvm.org/D76151 accordingly to allow .section .eh_frame,"a",@progbits (canonical one is @unwind) To GNU as maintainers, should @unwind be accepted for non-x86? >Adding a whole new general section type (SHT_UNWIND) seems to accomplish >nothing than additional code for all existing psABIs. For _future_ psABIs >it might make sense to allocate and document an SHT_UNWIND now, but for >existing ones it doesn't seem to make much sense. (And for the general >type: would we then require this section type to be forever associated >with dwarf unwind info? What about ARM unwind info, that couldn't use >SHT_UNWIND then. Or would we leave the specific format of SHT_UNWIND to >the psABI, but still allow them to use that common section type despite >principal difference to other ABIs? All of those questions can be >answered in multiple ways with pros and cons for each, but they need to be >answered before a generic SHT_UNWIND could be introduced, at which point >it's even less obvious if we should even bother) >(FWIW, my personal opinion would be to document SHT_UNWIND in the gABI, >with psABI to clarify content; but to _not_ make use of it in existing >psABIs) +1 Clarifying in gABI that 0x70000001 (processor specific) could not be used for unrelated purposes would be nice... Sadly Xinuos (formerly SCO) stopped maintaing the website a few years ago.. >Ciao, >Michael. >P.S: I wish there would have been more implementations of the x86-64 psABI >right from the beginning ;-)