Home Original page

RFC: syntax for a section ordering file

Nick Clifton nickc@redhat.com
Fri Apr 26 10:32:15 GMT 2024 
Hi Fangrui,

> * Apple ld -order_file. lld's MachO port ld64.lld has ported the option.
>    The feature is like ld.lld --section-ordering-file='s superset with
>    filename support. The syntax also supports "x86_64:" prefix, but this
>    design seems quite unusual in linker features.
> 
>    This option is used by iOS mobile applications.
> 
>    example:
>    https://github.com/llvm/llvm-project/blob/main/lld/test/MachO/order-file.s

Hmm, the order files in that example appear to be specifying the order of symbols
relative to each other, rather than sections.  Presumably the code locates the
input section containing the symbol and places it before/after the input section
containing the other symbol.  Assuming that both sections are going to be mapped
onto the same output section.

I am not sure about usefulness of the architecture specifiers.  I would have
thought that if necessary the build system could have per-architecture ordering
files.


> * gold --section-ordering-file=: which might be most similar to this patch.
>    I believe this option is effectively unused in the wild.

I have had reports from customers saying that one of the reasons they do not
want to switch from gold to lld or ld.bfd is that they use gold's section
ordering file option.


>    People find the section-based naming approach too inconvenient.
>    This is incompatible with sections that are not suffixed and clang
>    -fno-unique-section-names.

I did not know about that option.  Thanks for pointing it out.

Maybe an approach based upon symbol names would be better.  Harder
to implement, but better from a user's point of view...  Hmm.


> * ld.lld --symbol-ordering-file=:
> 
>    This option is used by Android and regular Linux folks focusing on server performance.
> 
>    example:
>    https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/symbol-ordering-file.s
> 
>    I have some notes at
>    https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#symbol-ordering-filefile

Very hepful.  I wish that I had read this before starting to adapt H.J.'s code...


>>  To my mind if the section ordering file contains the following:
>>
>>     # A comment
>>    .text.hot .text.cold,.text.warm
>>    .data.big
>>    .data.small
>>    .text.foo*
> 
>>  Then this should be roughly equivalent to:
>>
>>  SECTIONS
>>  {
>>    .text : {
>>      *(.text.hot)
>>      *(.text.cold)
>>      *(.text.warm)
>>      *(.text.foo*)
>>      *(.text)
>>      }
>>    .data : {
>>      *(.data.big)
>>      *(.data.small)
>>      *(.data)
>>      }
>>  }
>>
>>  So all of the .text.<something> entries in the section ordering
>>  file are placed at the start of the output .text section (even
>>  if some of them occur after entries for other output sections)
>>  and all of the .data.<something> entries are placed at the start
>>  of the .data section.
>>
>>  This will require co-operation from the linker script to have
>>  the "INCLUDE config.section-ordering-file" statements at the
>>  correct places, but I think that it could work.
> 
> Hmm.  I am curious why the first INCLUDE (in .text) does not append
> .data.big/.data.small (as requested).

Because the entries in the ordering file are matched to the output
section name.  So an entry that starts with .text will be matched
to the .text output section and an entry that starts with .data
will be matched to the .data output section.

In the updated patch now posted to the binutils list, I have also
implemented an explicit section name matching feature.  So if the
entry in the ordering file looks like this:

    .text(.data)

then it will be matched to the .text output section and will place
all input sections called .data at that point in the output.

Cheers
   Nick
More information about the Binutils mailing list