RFC: Usefulness of SHT_X86_64_UNWIND

[H.J. Lu]

If I understand correctly, SHT_X86_64_UNWIND was added so that linker
can group all
SHT_X86_64_UNWIND sections together without checking .eh_frame section name.
Other than that, linker treats .eh_frame like SHT_PROGBITS sections. Since
.eh_frame is also listed as a special section, similar to .got and
.plt, it makes
SHT_X86_64_UNWIND unnecessary and leads confusion:

https://sourceware.org/pipermail/libc-alpha/2020-March/111808.html

Because of this, i386 psABI only specifies special .eh_frame section
without SHT_386_UNWIND.

Should we remove SHT_X86_64_UNWIND and make x86-64 psABI
consistent with Linux gABI, similar to i386 psABI:

https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI

--
H.J.

[Fangrui Song]

I vote for deleting SHT_X86_64_UNWIND.

As I mentioned in https://sourceware.org/pipermail/libc-alpha/2020-March/111882.html ,
I can clean things on clang side.

[Ali Bahrami]

On 3/13/20 12:09 PM, 'Fangrui Song' via X86-64 System V Application Binary Interface wrote:
> On 2020-03-13, H.J. Lu wrote:
>> If  I understand correctly, SHT_X86_64_UNWIND was added so that linker
>> can group all
>> SHT_X86_64_UNWIND sections together without checking .eh_frame section name.
>> Other than that, linker treats .eh_frame like SHT_PROGBITS sections.   Since
>> .eh_frame is also listed as a special section, similar to .got and
>> .plt, it makes
>> SHT_X86_64_UNWIND unnecessary and leads confusion:
>>

>> https://urldefense.com/v3/__https://sourceware.org/pipermail/libc-alpha/2020-March/111808.html__;!!GqivPVa7Brio!JV2jr4SKIDe93dMWxRibehO72o-M8K35hsWfNlTK9frm4AK64dReZuUhh3J8caFw$

>> Because of this, i386 psABI only specifies special .eh_frame section
>> without SHT_386_UNWIND.
>>
>> Should we remove SHT_X86_64_UNWIND and make x86-64 psABI
>> consistent with Linux gABI, similar to i386 psABI:
>>

>> https://urldefense.com/v3/__https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI__;!!GqivPVa7Brio!JV2jr4SKIDe93dMWxRibehO72o-M8K35hsWfNlTK9frm4AK64dReZuUhh38jIQ9H$

>
> I vote for deleting SHT_X86_64_UNWIND.
>

> As I mentioned in https://urldefense.com/v3/__https://sourceware.org/pipermail/libc-alpha/2020-March/111882.html__;!!GqivPVa7Brio!JV2jr4SKIDe93dMWxRibehO72o-M8K35hsWfNlTK9frm4AK64dReZuUhh-Mi0Wmr$  ,

> I can clean things on clang side.
>

Sometimes, the effort to erase old mistakes just complicates
things further.

I think its too late for this. The world is full of objects
with SHT_X86_64_UNWIND set. You can stop producing it for new
objects, but you can't remove the old support. As such, nothing
becomes simpler than it was before. Hence, I don't see the point
of changing the status quo. We've all developed working code that
understands unwind sections can be either SHT_X86_64_UNWIND, or
SHT_PROGBITS. It's a solved problem, and not a big deal.

Hence, I vote a weak "no", Weak, because we probably won't
change anything in our implementation either way, so it
doesn't really have any practical impact. This seems like
unnecessary churn.

I would argue that the real historical mistake here was in
ever using SHT_PROGBITS for these sections. We could have
defined a generic SHT_UNWIND section type for all platforms.
Of course, it's too late for that as well.

- Ali

[Fāng-ruì Sòng]

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://reviews.llvm.org/rL252300 ).
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.

> Hence, I vote a weak "no", Weak, because we probably won't
> change anything in our implementation either way, so it
> doesn't really have any practical impact. This seems like
> unnecessary churn.

In very few cases people write .section .eh_frame,"aw",@unwind in assembly.

> I would argue that the real historical mistake here was in
> ever using SHT_PROGBITS for these sections. We could have
> defined a generic SHT_UNWIND section type for all platforms.
> Of course, it's too late for that as well.

I am going to teach clang to do the following if we move forward and
delete SHT_X86_64_UNWIND from x86-64 psABI:

unsigned EHSectionType = ELF::SHT_PROGBITS;
unsigned EHSectionFlags = ELF::SHF_ALLOC;
// Solaris requires different flags for .eh_frame to seemingly every other
// platform.
if (T.isOSSolaris()) {
if (T.getArch() == Triple::x86_64)
EHSectionType = ELF::SHT_X86_64_UNWIND;
else
EHSectionFlags |= ELF::SHF_WRITE;
}

Will be appreciated if you can tell me why SHF_WRITE is there:)
(SHF_WRITE really made me sad while fixing
https://github.com/libffi/libffi/pull/546/files )


--
宋方睿

[Ali Bahrami]

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.

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.

> 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.

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.

- Ali

[Fāng-ruì Sòng]

Original thread: https://groups.google.com/forum/#!topic/x86-64-abi/7sr4E6THl3g

+gnu-gabi and binutils

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.

"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.

I don't:) So it looks like https://github.com/libffi/libffi/pull/546 can be further simplified by deleting SHF_WRITE support completely.

[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

[Jan Beulich]

On 13.03.2020 19:27, Ali Bahrami wrote:
> I would argue that the real historical mistake here was in
> ever using SHT_PROGBITS for these sections. We could have
> defined a generic SHT_UNWIND section type for all platforms.
> Of course, it's too late for that as well.

+1 - I've always been puzzled by _all_ those abuses of section
names to infer what a section contains. There's a reason SHT_*
exist (and can be extended, including in a per-CPU and per-OS
manner). Therefore I'd vote against a deletion of any properly
provided SHT_* values.

Jan

[Michael Matz]

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

[Fāng-ruì Sòng]

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..

[Carlos O'Donell]

I agree. We should use SHT_* values for this purpose.

A a libc maintainer I empathize with Ali's point about having to
carry backwards compatible code forever.

If one adopts a long-term view of the maintenance of the standard
then it makes sense, at least to me, to retain documentation for
the existing SHT_* entries, but also try to improve clarity and
technical precision.

I applaud HJ for looking for places where we might tidy up or
tighten the standard, even if deleting SHT_* entries isn't something
I particularly agree with.

--
Cheers,
Carlos.

[Cary Coutant]

Agreed. I've fought a losing battle against depending on section names for many years.

At the time we defined processor-specific section types for unwind information for PA-RISC and (later) Itanium, it did seem more psABI-specific than generic. I honestly don't remember whether I lacked the foresight then to argue for a generic section type, or whether I did argue for it but got outvoted. I regret not pushing for it then.

-cary

 

[Ali Bahrami]

On 3/16/20 3:45 PM, Cary Coutant wrote:
> At the time we defined processor-specific section types for unwind information for PA-RISC and (later) Itanium, it did seem more psABI-specific than generic. I honestly don't remember whether I lacked the foresight then to argue for a generic section type, or whether I did argue for it but got outvoted. I regret not pushing for it then.

I learned about these sections backwards, starting with
x86_64, wondering why unwind is progbits on the other platforms,
and then learning about how GNU derived them from the Itanium ABI.
Looking backwards like that, it's easy to see how an opportunity
was missed.

It's a lot harder to catch those things going forward. I'm not at
all surprised that the original work at HP was viewed as platform
specific. How were you to know then that your work would be copied
into it's current form? I doubt that SHT_UNWIND could have been
justified then.

If there's a point to criticize, it might be the moment at which
we created SHT_X86_64_UNWIND, without taking a pause to consider
all the existing unwind sections on other architectures. At that
point, we might have created the generic SHT_UNWIND instead of
SHT_X86_64_UNWIND.

Oh well, next time. :-)

- Ali

[Florian Weimer]

* Jan Beulich:

I wasn't around when all this happened, but what I've seen more
recently is that people are comfortable with making up section names,
but allocating a new section type number is more difficult.

(I have tried to obtain a number in the past, but could not get one.)

I agree that using section types to guide the link editor better fits
the ELF model, but it requires active maintenance of the ELF
specification.

[Carlos O'Donell]

Who owns the standard right now and how do we actually get changes?

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/20/20 2:42 AM, Florian Weimer wrote:
> I wasn't around when all this happened, but what I've seen more
> recently is that people are comfortable with making up section names,
> but allocating a new section type number is more difficult.
>
> (I have tried to obtain a number in the past, but could not get one.)
>
> I agree that using section types to guide the link editor better fits
> the ELF model, but it requires active maintenance of the ELF
> specification.

The generic hurdle to using section types is that the linkers
have to be updated first, and then you have to wait awhile for
them to be deployed before you can use them. I've had more than
one GNU developer tell me that this becomes a big problem in the
GNU world, where different parts of the toolchain are developed
by different groups. It also makes it hard for old linkers to
cope with objects from new compilers, a debatable practice, but
one that happens. It also means that you need to really be sure
of the feature before rolling it out, because it's harder to tweak
small mistakes you discover later.

I'm pretty sure that this is why there's so much "by name" in
this world, and not the lack of a gABI maintainer. That's not to
say that the lack of a gABI maintainer isn't a problem, because
it is. But note that this "by-name" business predates the gABI
maintainer disappearing. And there's always the GNU OSABI.

Although I don't like seeing names used this way, I certainly
didn't mean for it to be interpreted as criticism to be directed
at any individuals who made those choices. My point in mentioning
it was to argue against the idea of trying to retro-simplify the
situation by adding more layers.

The biggest hurdle to new gABI features is that they need to
be truly generic, with no requirements for anything from the
OS or platform ABIs. It's a high bar. And then of course, the
lack of someone to accept it, and put it in the document is
certainly a problem.

It's why I half jokingly suggested recently that the gABI might
be "done". Future action will probably be concentrated in the OSABI.
And there is a certain history of different OSABI's adopting
the same concept. It's not as pure as a generic item, but it works.
Here are some examples from the Solaris <sys/elf.h>

/*
* PT_SUNW_UNWIND and PT_SUNW_EH_FRAME perform the same function,
* providing access to the .eh_frame_hdr section of the object.
* PT_SUNW_UNWIND is the original value, while PT_SUNW_EH_FRAME is
* required by the amd64 psABI. The Solaris link-editor (ld) tags output
* objects with PT_SUNW_UNWIND, but the Solaris runtime linker (ld.so.1)
* will accept and use either value.
*/
#define PT_SUNW_UNWIND 0x6464e550
#define PT_SUNW_EH_FRAME 0x6474e550
#define PT_GNU_EH_FRAME PT_SUNW_EH_FRAME
...
#define SHT_SUNW_verdef 0x6ffffffd
#define SHT_GNU_verdef SHT_SUNW_verdef
#define SHT_SUNW_verneed 0x6ffffffe
#define SHT_GNU_verneed SHT_SUNW_verneed
#define SHT_SUNW_versym 0x6fffffff
#define SHT_GNU_versym SHT_SUNW_versym
...
/*
* GNU/Linux OSABI specific values with different meanings than under Solaris.
* Due to the overlap in assigned values with the Solaris OSABI, correct
* interpretation of these values requires knowledge of the OSABI used by
* the object.
*/
#define SHT_GNU_ATTRIBUTES 0x6ffffff5 /* Object attributes */
#define SHT_GNU_HASH 0x6ffffff6 /* GNU-style hash table */
#define SHT_GNU_LIBLIST 0x6ffffff7 /* Prelink library list */

There are probably others, but I think you get the idea. You
could extend the GNU OSABI with new section types, and then the
rest of us might follow suit later if we like a particular feature,
and add it to our own OSABI. And in lucky cases, like ELF symbol
versioning, we might even be able to arrange to use the same
numeric value, though that's not really required.

Sorry for the length of this, I hope it was more useful than
noisy.

- Ali

[mas...@google.com]

What's the resolution? If we are going to document SHT_PROGBITS as another supported section type of .eh_frame in x86-64 psABI,

we can drop https://sourceware.org/pipermail/libc-alpha/2020-March/111808.html ,

otherwise I hope that patch can be considered.

On Friday, March 20, 2020 at 7:36:53 AM UTC-7 Ali.B...@Oracle.COM wrote:

On 3/20/20 2:42 AM, Florian Weimer wrote:
> I wasn't around when all this happened, but what I've seen more
> recently is that people are comfortable with making up section names,
> but allocating a new section type number is more difficult.
>
> (I have tried to obtain a number in the past, but could not get one.)
>
> I agree that using section types to guide the link editor better fits
> the ELF model, but it requires active maintenance of the ELF
> specification.

The generic hurdle to using section types is that the linkers
have to be updated first, and then you have to wait awhile for
them to be deployed before you can use them. I've had more than
one GNU developer tell me that this becomes a big problem in the
GNU world, where different parts of the toolchain are developed
by different groups. It also makes it hard for old linkers to
cope with objects from new compilers, a debatable practice, but
one that happens. It also means that you need to really be sure
of the feature before rolling it out, because it's harder to tweak
small mistakes you discover later.

I'm pretty sure that this is why there's so much "by name" in
this world, and not the lack of a gABI maintainer. That's not to
say that the lack of a gABI maintainer isn't a problem, because
it is. But note that this "by-name" business predates the gABI
maintainer disappearing. And there's always the GNU OSABI.

Agreed. I don't like so much "by name".

[Carlos O'Donell]

On 3/20/20 10:36 AM, Ali Bahrami wrote:
> Sorry for the length of this, I hope it was more useful than
> noisy.

It was useful. I appreciate the perspective it gives.

I still think that as a lagging standard we might document
common practice like SHT_UNWIND and avoid *ALL* new ports from
having to go define their own.

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/28/20 6:10 PM, Carlos O'Donell wrote:
> I still think that as a lagging standard we might document

> common practice like SHT_UNWIND and avoid*ALL* new ports from

> having to go define their own.

If the consensus was to do that, I'd be more than willing to
join in. Consider everything that entails though:

- We need to define SHT_UNWIND from the generic range, in the
gABI.

- I've always wondered why .eh_frame and .eh_frame_hdr
are both considered to be SHT_X86_64_UNWIND, even though
they contain different data, and can't be combined. If we're
willing to revisit unwind sections like this, should we create
2 new types, one for each? We'd have to discuss and work that
out.

- There's currently a program header in the OSABI range that
is used to find .eh_frame_hdr (PT_GNU_EH_FRAME,
PT_SUNW_EH_FRAME, etc). We would need to define a generic
replacement (like PT_UNWIND) to replace these.

- All existing code that handles these sections and program
headers would need to be modified to handle these new generic
shdr and phdr types as well. However, no old code could ever
be removed, so the net complexity goes up, both in code, and
in documentation.

- psABIs need to be updated to retain, but deprecate, the old
values.

Ideally, after doing all that, we won't have added any new abilities,
and will return to roughly where we started.

Alternatively, new ports could just define their own SHT_XXX_UNWIND
code, and use the existing framework, which while not ideal, is quite
functional.

- Ali

[Carlos O'Donell]

On 3/30/20 11:22 AM, Ali Bahrami wrote:
> On 3/28/20 6:10 PM, Carlos O'Donell wrote:
>> I still think that as a lagging standard we might document
>> common practice like SHT_UNWIND and avoid*ALL*  new ports from
>> having to go define their own.
>
>    If the consensus was to do that, I'd be more than willing to
> join in. Consider everything that entails though:

- Define some kind of process that identifies stakeholders, and uses
some kind of consensus to resolve the addition of new values.

>     - We need to define SHT_UNWIND from the generic range, in the
>       gABI.

Yes.

>     - I've always wondered why .eh_frame and .eh_frame_hdr
>       are both considered to be SHT_X86_64_UNWIND, even though
>       they contain different data, and can't be combined. If we're
>       willing to revisit unwind sections like this, should we create
>       2 new types, one for each? We'd have to discuss and work that
>       out.

Adding to that:

What do we do with .gcc_except_table?

Should we review Arm's unwind specifications which are different?

>     - There's currently a program header in the OSABI range that
>       is used to find .eh_frame_hdr (PT_GNU_EH_FRAME,
>       PT_SUNW_EH_FRAME, etc). We would need to define a generic
>       replacement (like PT_UNWIND) to replace these.

Also a good question.

I know why we have PT_GNU_EH_FRAME, and we could discuss that, I expect
it's the same reason as why Sun has it. And I think it is derivable from
first principles so I think we would need it.

>     - All existing code that handles these sections and program
>       headers would need to be modified to handle these new generic
>       shdr and phdr types as well. However, no old code could ever
>       be removed, so the net complexity goes up, both in code, and
>       in documentation.

The cost is created by choices _you_ make as an implementer which are
independent of what we have documented in the standard.

I could lobby for GNU Binutils to throw all the old code away at some point
and we'd have a cleaner implementation, but there would be initial costs
to pay for future payoff.

>     - psABIs need to be updated to retain, but deprecate, the old
>       values.
>

Yes.

> Ideally, after doing all that, we won't have added any new abilities,
> and will return to roughly where we started.

Yes.

> Alternatively, new ports could just define their own SHT_XXX_UNWIND
> code, and use the existing framework, which while not ideal, is quite
> functional.

I find this position to be a cost optimization on a short time horizon,
and I dislike it because of the choice of time horizon.

I see similarities here to the Linux kernel's large push to standardize
the process of adding a new port e.g. asm-generic, UAPI etc.

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/30/20 10:10 AM, Carlos O'Donell wrote:
> The cost is created by choices_you_ make as an implementer which are

> independent of what we have documented in the standard.
>
> I could lobby for GNU Binutils to throw all the old code away at some point
> and we'd have a cleaner implementation, but there would be initial costs
> to pay for future payoff.
>
>>     - psABIs need to be updated to retain, but deprecate, the old
>>       values.
>>

...

>> Alternatively, new ports could just define their own SHT_XXX_UNWIND
>> code, and use the existing framework, which while not ideal, is quite
>> functional.
> I find this position to be a cost optimization on a short time horizon,
> and I dislike it because of the choice of time horizon.
>
> I see similarities here to the Linux kernel's large push to standardize
> the process of adding a new port e.g. asm-generic, UAPI etc.

I'm not sure the cases are similar. The Linux kernel is
free to change their build processes, and break old practices,
if they see it as valuable enough to be worth the change. A change
like that affects a relatively small number of people, and all
that's requires is that enough of them be on board. Like most
software, sometimes you make a choice to make a break with
old practices and improve things.

Objects are different. There are billions of them, scattered
on machines all around the world, some very old, and some
with missing source code. Not everyone keeps up with the
latest stuff, or cares what toolchain folks like us think
they should do. We could of course, burn those compatibility
bridges for those folks, in the interest of progress, but you
shouldn't underestimate their numbers, or the amount of anger
and loss of trust a change like this will provoke.

Object file formats are usually manged in a much more
conservative manner. If an object is produced, following
the rules of a given ABI, it's almost never the case that
we'd later make a change that makes those objects unusable.
The few cases I'm aware of where that's happened were done
because the features weren't actually used, and you could
prove it, or because they were so broken that there was no
way to redeem them, so again, few if any users. In the case
of UNWIND, the existing feature is widely (massively) used,
and not broken. I don't think I've ever seen compatibility
for something like that withdrawn.

To frame it another way, I think the "some point" in your
plan would have to be so far in the future that it wouldn't
really matter. Otherwise, your user base will rebel.

If it's a choice, that choice seems very hypothetical to me.
I'm stuck supporting all the possibilities, and I think that
others will most likely find themselves in the same position.
You already know that I'd rather live in the pure SHT_UNWIND
world, but I just can't see how it would be worth it.

- Ali

[Carlos O'Donell]

On 3/30/20 2:08 PM, Ali Bahrami wrote:
> On 3/30/20 10:10 AM, Carlos O'Donell wrote:
>> I see similarities here to the Linux kernel's large push to standardize
>> the process of adding a new port e.g. asm-generic, UAPI etc.
>
>    I'm not sure the cases are similar. The Linux kernel is
> free to change their build processes, and break old practices,
> if they see it as valuable enough to be worth the change. A change
> like that affects a relatively small number of people, and all
> that's requires is that enough of them be on board. Like most
> software, sometimes you make a choice to make a break with
> old practices and improve things.

I would say this is a difference of scale, but still similar.

> Objects are different. There are billions of them, scattered
> on machines all around the world, some very old, and some
> with missing source code. Not everyone keeps up with the
> latest stuff, or cares what toolchain folks like us think
> they should do. We could of course, burn those compatibility
> bridges for those folks, in the interest of progress, but you
> shouldn't underestimate their numbers, or the amount of anger
> and loss of trust a change like this will provoke.

(a) New toolchains.

Is it valuable for you to be able to create a new toolchain
today, using the standard, and get something that is correct
and minimal? This isn't an abstract argument, we see new
toolchains being put together today for Intel's SGX enclaves.

(b) New developers.

Is it valuable to be able to train new developers and explain
SHT_UNWIND once? Ignoring the "compat.c" file that does all
the auxiliary by-name processing for legacy objects.

(c) Business models.

Is it valuable to be able to ship two products, a legacy one
without SHT_UNWIND, and a new forked code base cleaned up and
using only SHT_UNWIND? The latter having a reduction in coverage
and static analysis reviews for developers and QE. The former
seeing far fewer updates and releases to control cost.

> If it's a choice, that choice seems very hypothetical to me.
> I'm stuck supporting all the possibilities, and I think that
> others will most likely find themselves in the same position.
> You already know that I'd rather live in the pure SHT_UNWIND
> world, but I just can't see how it would be worth it.

Consensus on new features is most certainly based on individual
value judgements, and once something is implemented the value
likely decreases. Yet we are looking at a lagging standard,
where everything is already implemented, is there any value in
standardizing anything? I would say: Yes, see (a), (b) and (c)
above. Without considering "new" products and people we fail
to realize some of the value of a standard.

Yes, I agree with you, SHT_UNWIND has implementation costs.

Are there any other objections?

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/30/20 2:19 PM, Carlos O'Donell wrote:
> Yes, I agree with you, SHT_UNWIND has implementation costs.
>
> Are there any other objections?

No, I think I've said my piece. I do want to say though that
while SHT_UNWIND has implementation costs, I don't see that as
the important point. To me, it's about compatibility costs.

My argument was that providing SHT_UNWIND with compatibility
doesn't really make the world simpler, but I could live with it.
Since simplification was the goal, it seems not to be a big win
Here, cost might be a factor, but the task is easy enough that I'm
not really worried about it.

Your response is that providing compatibility is a choice, and that
we might simplify by dropping it, and that there would be payoffs
for developers in doing so. Here, we differ. The benefits seem
small, and the compatibility costs large. I won't willingly drop
support for the old stuff, but as you've said, nothing is forcing
me to.

Is this really worth it? It's not that hard to explain the current
UNWIND story to developers, though it would be nice if there was
a well written blog or something like that to point at, so that
we don't have to repeat ourselves.

Thanks for a great discussion.

- Ali

[Carlos O'Donell]

"Standards are the distilled wisdom of people with expertise in
their subject matter and who know the needs of the organizations
they represent" --- The British Standards Institution.

I think this is more wisdom to distill here :-)

--
Cheers,
Carlos.

[Michael Matz]

Hello,

On Mon, 30 Mar 2020, Carlos O'Donell wrote:

> I could lobby for GNU Binutils to throw all the old code away at some
> point and we'd have a cleaner implementation,

Certainly not. If you develop a new toolchain in 10 years from now, maybe
you won't need to include support for the currently existing values. But
the existing toolchain need to continue handling it.

> but there would be initial costs to pay for future payoff.

Therefore the future payoff will be very small. I _still_ would like the
(optional for now) support for common values in the gABI, with all caveats
and details Ali brought up.

> > Alternatively, new ports could just define their own SHT_XXX_UNWIND
> > code, and use the existing framework, which while not ideal, is quite
> > functional.
>
> I find this position to be a cost optimization on a short time horizon,
> and I dislike it because of the choice of time horizon.

I don't think so. In all truth the matter we're discussing is a very
minor detail of the implementation. If the value for SHT_FOO_UNWIND (and
associated values) is in OSABI or general range, or even happens to be the
same as SHT_PROGBITS, is hugely irrelevant in the grand scheme of
things, so that the time horizon for any choice is basically: forever.

There is a small but non-zero value in consistency in this matter, but
please don't overstate it. To me this smallish value is larger than the
implementation cost plus the maintenance cost of two solutions in the
future, which is why I argue for adding a gABI value, but it's not in any
way a very important matter.

> I see similarities here to the Linux kernel's large push to standardize
> the process of adding a new port e.g. asm-generic, UAPI etc.

Not really. Right now the process for deriving a new FOO psABI for the
matter at hand is "/SHT.*_UNWIND/s/X86_64/FOO/" or
"s/SHT.*_UNWIND/SHT_PROGBITS/", which is not at all in the same ball-park
as having to provide either standardized or custom APIs.


Ciao,
Michael.

[Carlos O'Donell]

On 3/31/20 9:13 AM, Michael Matz wrote:
> Hello,
>
> On Mon, 30 Mar 2020, Carlos O'Donell wrote:
>
>> I could lobby for GNU Binutils to throw all the old code away at some
>> point and we'd have a cleaner implementation,
>
> Certainly not. If you develop a new toolchain in 10 years from now, maybe
> you won't need to include support for the currently existing values. But
> the existing toolchain need to continue handling it.

I could lobby. I might not succeed.

I'm taking the position of devil's advocate here because I'm curious what our
internal position would be on these issues if someone else came in to argue
for new features in a new toolchain.

My own position, particularly as a glibc maintainer, is very conservative,
but I want to be open at the standard level to others who have different
value judgements or requirements.

The distilled wisdom in the room seems to be that if we did it again we
would argue for SHT_UNWIND, so why aren't we documenting best practice?

The position that Ali seems to advocate, and so do others, is that there is
a non-zero implementation cost to follow the standard, and the general
consensus is that this cost is arguably related to the cost of cleaning up.

My argument is that the cost of the implementation is just one part of the
cost, and I see you agree with that.

>> but there would be initial costs to pay for future payoff.
>
> Therefore the future payoff will be very small. I _still_ would like the
> (optional for now) support for common values in the gABI, with all caveats
> and details Ali brought up.

Agreed.

>>> Alternatively, new ports could just define their own SHT_XXX_UNWIND
>>> code, and use the existing framework, which while not ideal, is quite
>>> functional.
>>
>> I find this position to be a cost optimization on a short time horizon,
>> and I dislike it because of the choice of time horizon.
>
> I don't think so. In all truth the matter we're discussing is a very
> minor detail of the implementation. If the value for SHT_FOO_UNWIND (and
> associated values) is in OSABI or general range, or even happens to be the
> same as SHT_PROGBITS, is hugely irrelevant in the grand scheme of
> things, so that the time horizon for any choice is basically: forever.

If you accept that the time horizon is forever, then I think that Ali's
point about the gABI being "done" is true.

What is our incentive to put anything into the gABI?

What is our incentive to stop doing work only in our OS-specific regions?

Professional pride?

> There is a small but non-zero value in consistency in this matter, but
> please don't overstate it. To me this smallish value is larger than the
> implementation cost plus the maintenance cost of two solutions in the
> future, which is why I argue for adding a gABI value, but it's not in any
> way a very important matter.

Just to be clear, you *do* support SHT_UNWIND then?

>> I see similarities here to the Linux kernel's large push to standardize
>> the process of adding a new port e.g. asm-generic, UAPI etc.
>
> Not really. Right now the process for deriving a new FOO psABI for the
> matter at hand is "/SHT.*_UNWIND/s/X86_64/FOO/" or
> "s/SHT.*_UNWIND/SHT_PROGBITS/", which is not at all in the same ball-park
> as having to provide either standardized or custom APIs.

I don't follow, could you expand on this please?

When I said I saw similarities I meant the following:

* The gABI attempting to standardize on SHT_UNWIND instead of various
per-arch values...

... is similar to...

* The Linux kernel attempting to standardize syscall numbers, and
syscall constants instead of various per-arch values (a mess).

In both cases they make adding a new port easier (though scale may be different
as Ali points out). The asm-generic ports just "drop" into glibc (an exageration,
but you get the point, it solves a problem).

--
Cheers,
Carlos.

[Michael Matz]

Hello,

On Tue, 31 Mar 2020, Carlos O'Donell wrote:

> The distilled wisdom in the room seems to be that if we did it again we
> would argue for SHT_UNWIND, so why aren't we documenting best practice?

Yes and because we're still discussing it :)

> The position that Ali seems to advocate, and so do others, is that there
> is a non-zero implementation cost to follow the standard, and the
> general consensus is that this cost is arguably related to the cost of
> cleaning up.

No, (my interpretation of) Alis position is rather that introducing
SHT_UNWIND now
(a) doesn't solve any problem we have now
(b) perhaps solves a future problem, but a very small one (creating new
psABI that then will just work without extra additions)
(c) doesn't simplify the world (because of having to support the existing
ugliness forever)
(d) increases complexity of the world (a very little bit, because of
having to support an additional value)
and that therefore, having SHT_UNWIND from the beginning would have been
the right thing, and introducing SHT_UNWIND now is okay, but not required.
In particular he was arguing against any claim (that was indeed made
upthread) that such introduction would simplify things. If my
interpretation is right, then I agree with that position :-) For what I
deduce from that position, see below.

> What is our incentive to put anything into the gABI?

Putting SHT_UNWIND into gABI: more professional pride or "strive for an
ideal world" than anything else, yes (that would be item (e) in my
position list). Putting "anything" into the gABI: depends on what.

> What is our incentive to stop doing work only in our OS-specific regions?
> Professional pride?

Like above, it depends. Meanwhile the gang on this and the generic-abi
list is encompassing enough that it seems always worthwhile to think about
the gABI when we introduce new concepts, because _in the abstract_
generics are better than specifics. In former times it sometimes simply
was infeasible to try to add to the gABI. But revisiting _old_ concepts
isn't as clear cut, it's not automatically the right thing.

> > There is a small but non-zero value in consistency in this matter, but
> > please don't overstate it. To me this smallish value is larger than the
> > implementation cost plus the maintenance cost of two solutions in the
> > future, which is why I argue for adding a gABI value, but it's not in any
> > way a very important matter.
>
> Just to be clear, you *do* support SHT_UNWIND then?

Yes, I do. Because from my items above I consider point (b)
solves-future and (e) abstract-cleanlyness worthwhile enough to offset
point (d) increases-complexity.

> >> I see similarities here to the Linux kernel's large push to standardize
> >> the process of adding a new port e.g. asm-generic, UAPI etc.
> >
> > Not really. Right now the process for deriving a new FOO psABI for the
> > matter at hand is "/SHT.*_UNWIND/s/X86_64/FOO/" or
> > "s/SHT.*_UNWIND/SHT_PROGBITS/", which is not at all in the same ball-park
> > as having to provide either standardized or custom APIs.
>
> I don't follow, could you expand on this please?

My point was that the psABI process above was so very much simpler than
considering internal kernel interfaces that a port can or must use, that
it can't be considered similar. Now I realize you mean various symbolic
constants like syscalls and such, not (internal) subsystem APIs within the
kernel. I agree that this is indeed similar. But do note that also the
other side of the medal is similar: existing syscall numbers that aren't
using the generic scheme (e.g. because it were ports from before those
existed) are _not_ retroactively renumbered or reintroduced (i.e. the
we-cant-get-rid-of-OSABI-UNWIND argument).

In any case, once Cary has his gABI rewrite ready, I think this all is
now just a matter of sending a diff ;-)


Ciao,
Michael.

[Carlos O'Donell]

On 3/31/20 12:04 PM, Michael Matz wrote:
> In any case, once Cary has his gABI rewrite ready, I think this all is
> now just a matter of sending a diff ;-)

Yes. Looking forward to it.

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/31/20 9:34 AM, Carlos O'Donell wrote:
> If you accept that the time horizon is forever, then I think that Ali's
> point about the gABI being "done" is true.
>
> What is our incentive to put anything into the gABI?
>
> What is our incentive to stop doing work only in our OS-specific regions?
>
> Professional pride?

There's some confusion here. I saw Michael's response
come in while I was writing this, and his interpretation
of what I said is what I intended.

My comment about the gABI being "done" was a frustrated reaction to
Xinous having dropped their maintenance without handing it off to anyone.
Cary is working on this, so perhaps the doors will be open again.

Above, you ask about incentive to put things into the gABI, but
note that you ran into opposition over removal, not addition.
The time horizon for removing non-defective and working features
in an object ABI is essentially forever. It's intentional that there
shouldn't be incentive to do that, because the number one feature
that an object format needs to provide is long term continuity.
I think it's amazing that ELF objects from 1989 still work, but
they only work because we've retained some old baggage to support them.

There is incentive to add new features of general value, as long as
they are obvious, and upwardly compatible. As discussed, we could add
SHT_UNWIND and the other supporting additions. We differed on the
notion of also removing old features. As to SHT_UNWIND itself, the
strongest objection I made was that it didn't seem like much of a
benefit at this late date.

The structure of ELF, with OSABI and gABI parts, is designed to
protect the core, while freeing different groups to innovate.
A certain amount of cross OSABI duplication is therefore built
into the system (UNWIND is not the only example), and it's not a
generally a big problem. Without perfect foresight (or a time machine),
and an unusually compelling argument, it's always going to be
really hard to put anything new directly into the gABI. That's
as it should be, but it can be frustrating.

- Ali

[Carlos O'Donell]

On 3/31/20 1:09 PM, Ali Bahrami wrote:
> On 3/31/20 9:34 AM, Carlos O'Donell wrote:
>> If you accept that the time horizon is forever, then I think that Ali's
>> point about the gABI being "done" is true.
>>
>> What is our incentive to put anything into the gABI?
>>
>> What is our incentive to stop doing work only in our OS-specific regions?
>>
>> Professional pride?
>
>    There's some confusion here. I saw Michael's response
> come in while I was writing this, and his interpretation
> of what I said is what I intended.
>
> My comment about the gABI being "done" was a frustrated reaction to
> Xinous having dropped their maintenance without handing it off to anyone.
> Cary is working on this, so perhaps the doors will be open again.

I look forward to it.

> Above, you ask about incentive to put things into the gABI, but
> note that you ran into opposition over removal, not addition.

My apologies for taking your comment out of context. My intent was to
carry forward the same feeling of frustration and ask: Why would a
lagging standard do any work at all if everything was already
implemented? I think Michael answered some of this by saying
that we should work together to attempt to standardize new features
as a way of refining and improving our solutions.

> The time horizon for removing non-defective and working features
> in an object ABI is essentially forever. It's intentional that there
> shouldn't be incentive to do that, because the number one feature
> that an object format needs to provide is long term continuity.

The number one feature that an object format needs to provide is
interoperability with the toolchain the user wants to use e.g. be
useful.

It may be that long-term continuity is our currently accepted best
practice for achieving usefulness, but it is not the question I ask
myself when facing a design challenge.

I appreciate the difference is subtle, but I believe that asking about
usefulness can yield different answers than asking about long-term
continuity.

Asking about usefulness places the focus on the user and their
experience with the feature.

> I think it's amazing that ELF objects from 1989 still work, but
> they only work because we've retained some old baggage to support them.

I am more amazed by the flexibility and forsight of the design and
that it still allows us to create new features within the existing
framework e.g. segments and Full RELRO, relocations and IFUNCs etc.

> There is incentive to add new features of general value, as long as
> they are obvious, and upwardly compatible. As discussed, we could add
> SHT_UNWIND and the other supporting additions. We differed on the
> notion of also removing old features. As to SHT_UNWIND itself, the
> strongest objection I made was that it didn't seem like much of a
> benefit at this late date.

We differed on the notion of cost/beneift for removing old features
*from software* that implements the ELF standard. This informs on the
decision to add SHT_UNWIND, because the lack of removal (a business
requirement) of the old feature means there are less tangible benefits
to implementations.

We didn't discuss if we should deprecate SHT_X86_64_UNWIND, which is
not part of the gABI.

> The structure of ELF, with OSABI and gABI parts, is designed to
> protect the core, while freeing different groups to innovate.
> A certain amount of cross OSABI duplication is therefore built
> into the system (UNWIND is not the only example), and it's not a
> generally a big problem. Without perfect foresight (or a time machine),
> and an unusually compelling argument, it's always going to be
> really hard to put anything new directly into the gABI. That's
> as it should be, but it can be frustrating.

Agreed, likewise with deprecation.

In summary:
- Adding features to the gABI should be hard.
- Deprecating features from the gABI should be hard.
- Focus on usefulness to users, and industry.
- Attempt to standardize in the gABI as a method of refinement
of new features.

--
Cheers,
Carlos.

[Ali Bahrami]

On 3/31/20 1:43 PM, Carlos O'Donell wrote:
> We differed on the notion of cost/beneift for removing old features
> *from software* that implements the ELF standard. This informs on the
> decision to add SHT_UNWIND, because the lack of removal (a business
> requirement) of the old feature means there are less tangible benefits
> to implementations.
>
> We didn't discuss if we should deprecate SHT_X86_64_UNWIND, which is
> not part of the gABI.

I thought we were discussing that, so this is helpful. :-)

I guess it depends what software you mean. If we removed SHT_X86_64_UNWIND
from the GNU linkers generally, that would cause a lot of chaos. If you
removed it from some specific system that you were developing, where the
old support had no value, that would be fine, and possibly a nice simplification
for that system.

> In summary:
> - Adding features to the gABI should be hard.
> - Deprecating features from the gABI should be hard.
> - Focus on usefulness to users, and industry.
> - Attempt to standardize in the gABI as a method of refinement
> of new features.

Yes, I think we're close enough here that there's no practical
difference in our views.

I don't see an unsolvable conflict between between continuity and
usefulness. I'm happy to consider them both "most important".
It's always about how to hit the right balance, and what we
can get away with safely.

Thanks.

- Ali

[Carlos O'Donell]

On 3/31/20 4:10 PM, Ali Bahrami wrote:
> On 3/31/20 1:43 PM, Carlos O'Donell wrote:
>> We differed on the notion of cost/beneift for removing old features
>> *from software*  that implements the ELF standard. This informs on the
>> decision to add SHT_UNWIND, because the lack of removal (a business
>> requirement) of the old feature means there are less tangible benefits
>> to implementations.
>>
>> We didn't discuss if we should deprecate SHT_X86_64_UNWIND, which is
>> not part of the gABI.
>
> I thought we were discussing that, so this is helpful. :-)

If we added SHT_UNWIND I would expect we would deprecate the use of
SHT_X64_64_UNWIND, but I would never remove it from the psABI.
Leaving it in the psABI allows implementation choice over how far
back anyone wants to support objects in their given ecosystem.

> I guess it depends what software you mean. If we removed SHT_X86_64_UNWIND
> from the GNU linkers generally, that would cause a lot of chaos. If you
> removed it from some specific system that you were developing, where the
> old support had no value, that would be fine, and possibly a nice simplification
> for that system.

My intent was to point out that there are no absolute values, that
implementers see value related to the expectations they set with
their users.

Fedora for example has no expectations set for cross major release
object compatibility, and so we might experiment with something
novel and suggest something new, and revert it in 6 months at the
next release boundary. A flatpak doesn't care if the ELF files in
the flatpak are different, just that they are consistent, and that
the flatpak runs. Similarly for containers. External introspection
is an orthogonal but relevant issue.

The number of people on this list is limited so the gamut of
expectations is probably fairly small.

I look forward to more input from interested parties including
musl, llvm, and the BSDs.

>> In summary:
>> - Adding features to the gABI should be hard.
>> - Deprecating features from the gABI should be hard.
>> - Focus on usefulness to users, and industry.
>> - Attempt to standardize in the gABI as a method of refinement
>>    of new features.
>
>
> Yes, I think we're close enough here that there's no practical
> difference in our views.
>
> I don't see an unsolvable conflict between between continuity and
> usefulness. I'm happy to consider them both "most important".
> It's always about how to hit the right balance, and what we
> can get away with safely.

Agreed.

--
Cheers,
Carlos.

[Fangrui Song]

On 2020-03-31, Carlos O'Donell wrote:
>On 3/31/20 4:10 PM, Ali Bahrami wrote:
>> On 3/31/20 1:43 PM, Carlos O'Donell wrote:
>>> We differed on the notion of cost/beneift for removing old features
>>> *from software*  that implements the ELF standard. This informs on the
>>> decision to add SHT_UNWIND, because the lack of removal (a business
>>> requirement) of the old feature means there are less tangible benefits
>>> to implementations.
>>>
>>> We didn't discuss if we should deprecate SHT_X86_64_UNWIND, which is
>>> not part of the gABI.
>>
>> I thought we were discussing that, so this is helpful. :-)
>
>If we added SHT_UNWIND I would expect we would deprecate the use of
>SHT_X64_64_UNWIND, but I would never remove it from the psABI.
>Leaving it in the psABI allows implementation choice over how far
>back anyone wants to support objects in their given ecosystem.

If we are to define

#define SHT_UNWIND 0x70000001 /* Unwind information. */

as a replacement of SHT_X86_64_UNWIND, this will probably just affect
the output of readelf -S and llvm-readobj(llvm-readelf) -S:

X86_64_UNWIND -> UNWIND

The ELF spec says:

SHT_LOPROC through SHT_HIPROC
Values in this inclusive range are reserved for processor-specific semantics.

Basically we deprived one value from the processor-specific range.
Processors still has the discretion to use the value for different
purposes, e.g. SHT_ARM_EXIDX. It can probably be made to this draft:
https://groups.google.com/forum/#!topic/generic-abi/cfOCv5Y0-B4

In GNU as and llvm-mc, we can reuse the x86 syntax:

.section .eh_frame,"a",@unwind

The above all seems fine to me and I will be happy to implement for
llvm-mc and llvm-readobj if the consensus is that we should do this.

>--
>You received this message because you are subscribed to the Google Groups "X86-64 System V Application Binary Interface" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to x86-64-abi+...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/x86-64-abi/299684d4-5f69-04d9-305c-042b99bb4238%40redhat.com.

[Ali Bahrami]

On 4/1/20 10:37 AM, Fangrui Song wrote:
> If we are to define
>
> #define SHT_UNWIND 0x70000001 /* Unwind information. */
>
> as a replacement of SHT_X86_64_UNWIND, this will probably just affect
> the output of readelf -S and llvm-readobj(llvm-readelf) -S:
>
>   X86_64_UNWIND -> UNWIND
>
> The ELF spec says:
>
>   SHT_LOPROC through SHT_HIPROC
>   Values in this inclusive range are reserved for processor-specific semantics.
>
> Basically we deprived one value from the processor-specific range.

I'm not wild about making psABI values into gABI ones though special
casing, particularly as it might get more complicated than just one value:

On 3/30/20 9:22 AM, Ali Bahrami wrote:
> - I've always wondered why .eh_frame and .eh_frame_hdr
> are both considered to be SHT_X86_64_UNWIND, even though
> they contain different data, and can't be combined. If we're
> willing to revisit unwind sections like this, should we create
> 2 new types, one for each? We'd have to discuss and work that
> out.
>

> - There's currently a program header in the OSABI range that
> is used to find .eh_frame_hdr (PT_GNU_EH_FRAME,
> PT_SUNW_EH_FRAME, etc). We would need to define a generic
> replacement (like PT_UNWIND) to replace these.

On 3/30/20 10:10 AM, Carlos O'Donell wrote:
> Adding to that:
>
> What do we do with .gcc_except_table?

I'll keep an open mind on this, but I'm a lot more concerned
about the long term conceptual clarity than I am about minimizing
the amount of code needed to adapt. These special cases are themselves
going to be confusing to the programmers of the future, so if
the goal is to clean up as much as possible for them, it might
be better to bite the bullet and create new generic assignments.

Also, there are a lot of other "shared" values across the OSABIs,
(e.g. symbol versioning) so once we open this door, how many
other things are we willing to see go through it? It could
get pretty complicated.

> In GNU as and llvm-mc, we can reuse the x86 syntax:
>
> .section .eh_frame,"a",@unwind

We could reuse the x86 syntax in either case, and I was
assuming we would. It's true though that if a new
SHT_UNWIND is allocated from the generic range, there would
need to be a code change to the assemblers
(s/SHT_X86_64_UNWIND/SHT_UNWIND), after waiting for linkers
with the necessary support to percolate into the world.

- Ali

[Michael Matz]

Hello,

On Wed, 1 Apr 2020, 'Fangrui Song' via X86-64 System V Application Binary Interface wrote:

> >>> We differed on the notion of cost/beneift for removing old features
> >>> *from software*  that implements the ELF standard. This informs on the
> >>> decision to add SHT_UNWIND, because the lack of removal (a business
> >>> requirement) of the old feature means there are less tangible benefits
> >>> to implementations.
> >>>
> >>> We didn't discuss if we should deprecate SHT_X86_64_UNWIND, which is
> >>> not part of the gABI.
> >>
> >> I thought we were discussing that, so this is helpful. :-)
> >
> >If we added SHT_UNWIND I would expect we would deprecate the use of
> >SHT_X64_64_UNWIND, but I would never remove it from the psABI.
> >Leaving it in the psABI allows implementation choice over how far
> >back anyone wants to support objects in their given ecosystem.
>
> If we are to define
>
> #define SHT_UNWIND 0x70000001 /* Unwind information. */
>
> as a replacement of SHT_X86_64_UNWIND, this will probably just affect
> the output of readelf -S and llvm-readobj(llvm-readelf) -S:
>
> X86_64_UNWIND -> UNWIND
>
> The ELF spec says:
>
> SHT_LOPROC through SHT_HIPROC
> Values in this inclusive range are reserved for processor-specific
> semantics.
>
> Basically we deprived one value from the processor-specific range.

Nah. The whole purpose of this excercise is to make the world a better
place for future generations. Putting psABI-range values into the gABI is
exactly the opposite.


Ciao,
Michael.