Rules for linking unrecognized SHF_LINK_ORDER sections

[Fangrui Song]

I know the ELF spec has been unmaintained since ~2015 and acknowledge the

sentence by Cary on https://groups.google.com/d/msg/generic-abi/eSDy2OTeQr8/C0gs3SYLAQAJ

> It was never the intent of the gABI to specify the details of how linkers should combine sections

I am sending the message just to ask about the most sensible behavior regarding

linking unrecognized SHF_LINK_ORDER sections.

The latest wording update about SHF_LINK_ORDER (unofficial but agreed by multiple

parties and implemented in more than one linkers) I can find is

https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/eGF9A0AnAAAJ

    SHF_LINK_ORDER

       This flag adds special ordering requirements for link editors. The

       requirements apply to the referenced section identified by the sh_link

       field of this section's header.  If this section is combined with other

       sections in the output file, the section must appear in the same

       relative order with respect to those sections, as the referenced

       section appears with respect to sections the referenced section is

       combined with.

       A typical use of this flag is to build a table that references

       text or data sections in address order.

       In addition to adding ordering requirements, SHF_LINK_ORDER indicates

       that the section contains metadata describing the referenced section.

       When performing unused section elimination, the link editor should

       ensure that both the section and the referenced section are retained

       or discarded together. Furthermore, relocations from this section

       into the referenced section should not be taken as evidence that the

       referenced section should be retained.

Say, we have two SHF_LINK_ORDER sections named foo. They link .init and .text, respectively.

sh_link(foo [1]) = .init

sh_link(foo [2]) = .text

(An output section description in a linker script can force the combination rules.

 Input section descriptions are name based. Mixing input sections linking to different sections is unavoidable.)

Question 1: Should the linker create two output sections foo? If there is only one output section,

the output section will contain two input sections linking different output sections (.init and .text).

The sh_link field may be arbitrarily set to one of .init and .text, or 0 to represent a mixed status.

Question 2: GNU ld compatible linkers define __start_sectionname / __stop_sectionname (even in the presence of an output section description of foo). When there are multiple output sections named 'foo', __start_foo/__stop_foo can only arbitrarily refer to one of them.

For linker implementers, shall we consider __start_sectionname / __stop_sectionname an ugly hack and say it does not work well with SHF_LINK_ORDER sections?

If so, can we provide an alternative to __start_sectionname / __stop_sectionname?

Note, from the execution view, the section header table is optional. __start_sectionname/__stop_sectionname can be made into DT_SYMTAB

[Cary Coutant]

> Say, we have two SHF_LINK_ORDER sections named foo. They link .init and .text, respectively.
>
> sh_link(foo [1]) = .init
> sh_link(foo [2]) = .text
>
> (An output section description in a linker script can force the combination rules.
> Input section descriptions are name based. Mixing input sections linking to different sections is unavoidable.)
>
> Question 1: Should the linker create two output sections foo? If there is only one output section,
> the output section will contain two input sections linking different output sections (.init and .text).
> The sh_link field may be arbitrarily set to one of .init and .text, or 0 to represent a mixed status.

The SHF_LINK_ORDER flag was added to generalize a requirement that we
had at HP for the SHT_*_UNWIND section type. In the presence of text
section reordering, we wanted the corresponding unwind section
contributions to maintain the same relative order (in other words, we
wanted to keep the unwind section sorted by the address of the text
that each unwind descriptor referred to). With that in mind, we wanted
all the unwind section contributions to combine into a single .unwind
output section, regardless of whether the corresponding text sections
were named .text or .text.cold, or whatever.

The sh_link field kind of loses its importance when building an
executable output; it's really only there to help the linker process
associated input sections. Therefore, even though we didn't explicitly
say it, I think it would be reasonable either to pick an arbitrary
output section or to put a 0 there.

> Question 2: GNU ld compatible linkers define __start_sectionname / __stop_sectionname (even in the presence of an output section description of foo). When there are multiple output sections named 'foo', __start_foo/__stop_foo can only arbitrarily refer to one of them.
> For linker implementers, shall we consider __start_sectionname / __stop_sectionname an ugly hack and say it does not work well with SHF_LINK_ORDER sections?
> If so, can we provide an alternative to __start_sectionname / __stop_sectionname?
> Note, from the execution view, the section header table is optional. __start_sectionname/__stop_sectionname can be made into DT_SYMTAB

I think my answer to the first question makes this one mostly moot.
With only one output section named foo, there's no issue here. I don't
think the issue is with SHF_LINK_ORDER, but there are other conditions
under which the linker might output two separate sections with the
same name, and I'd say that the __start/__stop convention is not
compatible with those conditions. If, however, you could place those
output foo sections consecutively with no gaps between them, you could
place the __start symbol at the beginning of the first, and the __stop
symbol at the end of the last.

-cary

[Fangrui Song]

On Thursday, March 19, 2020 at 4:18:48 PM UTC-7 Cary wrote:

> Say, we have two SHF_LINK_ORDER sections named foo. They link .init and .text, respectively.
>
> sh_link(foo [1]) = .init
> sh_link(foo [2]) = .text
>
> (An output section description in a linker script can force the combination rules.
> Input section descriptions are name based. Mixing input sections linking to different sections is unavoidable.)
>
> Question 1: Should the linker create two output sections foo? If there is only one output section,
> the output section will contain two input sections linking different output sections (.init and .text).
> The sh_link field may be arbitrarily set to one of .init and .text, or 0 to represent a mixed status.

The SHF_LINK_ORDER flag was added to generalize a requirement that we
had at HP for the SHT_*_UNWIND section type. In the presence of text
section reordering, we wanted the corresponding unwind section
contributions to maintain the same relative order (in other words, we
wanted to keep the unwind section sorted by the address of the text
that each unwind descriptor referred to). With that in mind, we wanted
all the unwind section contributions to combine into a single .unwind
output section, regardless of whether the corresponding text sections
were named .text or .text.cold, or whatever.

Thank you for sharing the history about the flag!

 

The sh_link field kind of loses its importance when building an
executable output; it's really only there to help the linker process
associated input sections. Therefore, even though we didn't explicitly
say it, I think it would be reasonable either to pick an arbitrary
output section or to put a 0 there.

> Question 2: GNU ld compatible linkers define __start_sectionname / __stop_sectionname (even in the presence of an output section description of foo). When there are multiple output sections named 'foo', __start_foo/__stop_foo can only arbitrarily refer to one of them.
> For linker implementers, shall we consider __start_sectionname / __stop_sectionname an ugly hack and say it does not work well with SHF_LINK_ORDER sections?
> If so, can we provide an alternative to __start_sectionname / __stop_sectionname?
> Note, from the execution view, the section header table is optional. __start_sectionname/__stop_sectionname can be made into DT_SYMTAB

I think my answer to the first question makes this one mostly moot.
With only one output section named foo, there's no issue here. I don't
think the issue is with SHF_LINK_ORDER, but there are other conditions
under which the linker might output two separate sections with the
same name, and I'd say that the __start/__stop convention is not
compatible with those conditions. If, however, you could place those
output foo sections consecutively with no gaps between them, you could
place the __start symbol at the beginning of the first, and the __stop
symbol at the end of the last.

-cary

Unwinding can be considered as a global thing. There does not have to be multiple SHT_*_UNWIND. For other metadata sections, combing SHF_LINK_ORDER output sections can potentially change the semantics.

 

[Cary Coutant]

> Unwinding can be considered as a global thing. There does not have to be multiple SHT_*_UNWIND. For other metadata sections, combing SHF_LINK_ORDER output sections can potentially change the semantics.

SHF_LINK_ORDER says nothing about separate output sections. If you
need the metadata sections for .text.foo to be in a separate output
section from those for .text.bar, you should name the metadata
sections accordingly, too.

-cary