Is this the change you were thinking of?

In D48756#1159410, @pcc wrote:

In D48756#1159376, @void wrote:

In D48756#1159339, @pcc wrote:

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.

It's certainly lost at compile time right now. Putting no-function-sections behind -r isn't as good as using the compile-time flags, but it seems like it would make things more likely to work in cases where the consumer of the output file cares about section names, so it seems like it would do until the flag gets hooked up properly.

Also, I believe I was seeing these function sections in non-.ko files (after the final link).

Can you double check which kind of files they were? It's possible that they were non-.ko relocatable files that might have been used to create the final image.

In 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

In D48756#1149891, @pcc wrote:

In D48756#1148415, @void wrote:

Though frankly if the user doesn't specify --segment-ordering-file, then I'm not sure why the default is for this to be true.

Because -function-sections and -data-sections allow for code size optimizations, specifically --gc-sections and --icf.

Then it should be dependent upon those options and not set true for every run. Note that given linkers don't normally create new sections for each function, running LTO on the program unexpectedly changes the resulting output. This isn't good, despite the fact that 99.99% of people may not notice a difference.

I changed it so that the original behavior is not changed. You need to specify disable-section-ordering as a plugin option.

Can I explain why it doesn't boot? No. At least not the root cause of why it won't boot. That's just the behavior we see. As I mentioned, Linux is very sensitive to what the linker is doing. E.g., we can't use the gold linker in the final binary link phase. If you wish, I can change the default here. Though frankly if the user doesn't specify --segment-ordering-file, then I'm not sure why the default is for this to be true.

Friendly ping. :-)

Fix logical operators. They return 1 or 0, not -1 or 0.

Add fix for MIPS test.

I have no more concerns with this patch.

Friendly ping? :-)

Hallo! I was wondering what the status of this patch was. :-)

LGTM

Unfortunately, I only vaguely recall this patch. Is there a reason not to
have support for both? I don't think we support POWER in LLVM though (I
could be wrong there) ... You may need to ask one of the ppc experts here.

I think there's some misunderstanding of what I'd like to see here. (I confused things by using 'null' for the example.) This is the type of code I was thinking of:

In D4256#10, @vhbit wrote:

Still need advice if it is possible to unify both aggregate type branches into one, as I'm not sure if there is a combination of codegen/optimization flags which might not eliminate loading from null.

This is crying out for a testcase. Can you supply one?