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

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 26 16:04:05 PDT 2016


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


More information about the llvm-commits mailing list