[PATCH] D24782: Do not merge input sections if --relocatable.

[Peter Smith via llvm-commits]

I've not been able to find anything online saying why kernel modules
chose to use relocatable objects. I agree that using shared objects,
or something similar would be simpler. I can only speculate that it
might be legacy or fear of performance loss. If I happen to bump into
a kernel hacker who can tell me I'll let you know.

Without using a linker script both ld.bfd and gold do not combine
.ARM.exidx sections or any section that there is a link order
dependency, the link order dependency is preserved. In effect similar
behaviour to my most recent patch. I've not experimented much with
linker scripts for ld -r.

You are correct that libunwind can use .ARM.exidx sections to unwind
the stack. A command line option is needed to get the compiler to
output unwind tables for C code, by default they will get a can't
unwind entry.

I'm not familiar enough with the ,eh_frame implementation to say for
certain, but I suspect that it will be ok as there isn't any
requirement for the .eh_frame to be in any particular order unless
there is the .eh_frame_hdr section, and that would only make sense to
create for an application or shared library.

Peter



On 26 September 2016 at 16:04, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 21 September 2016 at 03:40, Peter Smith via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>> peter.smith added a comment.
>>
>> 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.
>
>
> Do you know why it uses -r instead of -shared? Having the linker
> produce a .so should make something that is simpler to load.
>
>> - 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.
>
> Do you know what bfd and gold do? BTW, the .ARM.exidx sections are not
> just for exceptions, right? They are used for any stack unwinding.
>
> Is our .eh_frame handling already broken with -r?
>
> Cheers,
> Rafael