[PATCH] D48756: [gold-plugin] Add option for section ordering

[Bill Wendling via Phabricator via llvm-commits]

void added a comment.

In https://reviews.llvm.org/D48756#1159339, @pcc wrote:

> I think it's important to understand exactly how the Linux kernel is sensitive to being linked, so that once we understand the root cause, we can develop an appropriate fix. It may be that the root cause is a deliberate dependency on an implementation detail, but that doesn't necessarily mean that the right fix is to add a flag, it could mean that we can develop a more targeted fix that doesn't require a flag. Or it could just be a bug, in which case we can fix it uncontroversially without needing to add a flag. In general I think it's important to find a solution that avoids adding flags because that increases the maintenance burden of the program. Here's an excellent article I recently read that makes the point better than I can: http://neugierig.org/software/blog/2018/07/options.html


I'm not a fan of adding options either. However, the justification here is to fix the issue where the gold linker was making an assumption that didn't work for all programs. I also wanted the gold linker to replicate as much as possible "normal" linker behavior when LTO isn't used. In the non-LTO instance, we don't get function/data sections. Given these two things, we really need to supply a way for the programmer to turn this feature off when it doesn't suit their needs—either with a new option or using an existing one.

> I want to help you get this fixed, so I had one idea about what the root cause might be. Normally the linker will strip the name of the function from the output section when `-function-sections` is enabled, so `.text.foo` becomes `.text` in the output file. What that means is that without any special flags, `-function-sections` shouldn't normally change the output in any observable way. One case in which it is observable is when creating a relocatable object file with the `-r` flag. I happen to know that Linux kernel modules (`.ko` files) are represented as relocatable object files, so my suspicion is that the Linux kernel loader doesn't like section names of the form `.text.foo` in `.ko` files. If that's the case, a better fix would be to disable function sections only when creating a relocatable object file. That seems fine to me because relocatable files cannot usually be optimized by the linker. (What it probably also means is that in a later change we will want to save the `-ffunction-sections` and `-fdata-sections` flags passed at compile time and use them at link time. That would make things more complicated if we had just added a flag, because now we need to decide what to do if the link-time flag conflicts with the compile-time flag.) You can check whether `-r` was passed by checking whether the `LDPT_LINKER_OUTPUT` tag passed to the plugin is `LDPO_REL`.

The `-r` flag is being used, so your analysis is probably correct. From looking at the code, the kernel turns on function/data sections only when the `CONFIG_SPLIT_SECTIONS` option is set. The issue with disabling function sections for `.ko` files is that the gold linker doesn't know that they're turned off for those files. That information is lost because the command line information is lost. Also, I believe I was seeing these function sections in non-`.ko` files (after the final link).

We have a hack to "fix" function sections for live patching when `CONFIG_SPLIT_SECTIONS` is enabled. However, it aborted when I tried it on a normal build.


https://reviews.llvm.org/D48756