This is an archive of the discontinued LLVM Phabricator instance.

Do not merge input sections if --relocatable.
Needs ReviewPublic

Authored by ruiu on Sep 20 2016, 1:41 PM.

Details

Reviewers
peter.smith
Summary

This was discussed in https://reviews.llvm.org/D24728 and I think
it's worth to bring up as a separate and concrete patch so that
we can discuss about it.

This is a patch to disable section merging if --relocatable option
is given. Currently, if --relocatable is given, LLD produces a
relinkable object file, but multiple .text input sections are merged
together to produce a single .text output section (and so is true
for other regular output sections such as .data, .rodata, etc.)

Such behavior is the same as what GNU linkers do, which is an
obvious advantage, but it also has a few drawbacks.

First, it is not always easy to merge sections for --relocatable.
That is discussed in the review thread for D24728. For D24728,
we wanted to merge exception table for ARM, and merging .ARM.exidx
is tricky because we have to create corresponding sh_link sections
for a newly created output section. If we don't merge input sections,
but instead pass them through, we can eliminate that complexity
completely.

Second, --gc-sections and --icf doesn't work well for merged inputs.
Once we merge multiple .text secitons, the output is very likely to
be eliminated by --gc-sections on the final link.

Overall, I think not merging input sections is a better choice for us.
It is easier to impolement than merging sections and will yield
better final outputs. Therefore, I want to change the current behavior
with this change.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 71978.Sep 20 2016, 1:41 PM
ruiu retitled this revision from to Do not merge input sections if --relocatable..
ruiu updated this object.
ruiu added a reviewer: peter.smith.
ruiu added a subscriber: llvm-commits.
emaste added a subscriber: emaste.Sep 20 2016, 1:51 PM
peter.smith edited edge metadata.Sep 21 2016, 3:40 AM

I've done a bit of digging on the uses for ld -r relocatable. It seems to be that the primary and perhaps only use case for the existing behaviour of ld -r are relocatable kernel modules (on linux files with the .ko extension). Single file modules can be loaded directly by a simple linker/loader in the kernel, more complex ones are combined with ld -r (https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt).

My limited understanding of kernel modules is that they are written in C with no use of the standard library allowed. There is no support for C++ and certainly not C++ exceptions.

While I couldn't say for sure I would expect that a kernel module will rely on being "pre-processed" by ld -r first, if only to collate together the module id and some other custom sections.

As to what this tells us; I think the ability to combine sections has a reasonable use case. I don't think that trying to make all possible features work seamlessly with it is strictly necessary. Some possible options:

  • Do not support kernel modules, this would be a problem for freebsd if their kernel modules work this way. I'm sure linux kernel modules can/will use GNU ld.
  • ld -r works as it is but does not guarantee to support complicated cases like ARM C++ exceptions (error message given?)
  • ld -r works as it is when provided with a linker script, but by default it won't combine sections.
  • Make ld -r work, at least for those who are using its output as an input to another system linker.

I suspect that if freebsd's module system uses relocatable objects like Linux I think the existing behaviour of ld -r will be important enough to preserve in some form. Given that kernel modules don't support C++ I think it is acceptable, if not ideal, to not support ARM C++ exceptions with ld -r combining sections.

Some comments on the patch:

  • Last time I tried ld -r wasn't working at all with linker scripts but it will be worth checking that the ldscript interacts as expected. At present it looks like the individual InputSections are not combined, but they are renamed to whatever OutputSection they matched in the linker script.
  • The SHF_LINK_ORDER will still need a bit of added complexity, the sh_link to the InputSection will need to be updated to whatever the section index of the OutputSection is.