Re: SHT_UNWIND instead of SHT_X86_64_UNWIND? (was: RFC: Usefulness of SHT_X86_64_UNWIND)

[Michael Matz <matz@suse.de>]

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 ;-)