Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

From: Guenter Roeck
Date: Tue Sep 13 2016 - 16:25:29 EST


On 09/12/2016 08:51 PM, Nicholas Piggin wrote:
On Mon, 12 Sep 2016 20:17:30 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:

Hi Nicholas,

On 09/12/2016 07:00 PM, Nicholas Piggin wrote:
On Mon, 12 Sep 2016 15:24:43 -0700
Guenter Roeck <linux@xxxxxxxxxxxx> wrote:

Hi,

your commit 'kbuild: allow archs to select link dead code/data elimination'
is causing the following build failure in -next when building score:defconfig.

arch/score/kernel/built-in.o: In function `work_resched':
arch/score/kernel/entry.o:(.text+0xe84):
relocation truncated to fit: R_SCORE_PC19 against `schedule'

Reverting the commit fixes the problem.

Please let me know if I can help tracking down the problem.
In case you need a score toochain, you can find the one I use at
http://server.roeck-us.net/toolchains/score.tgz.

Thanks,
Guenter

It's not supposed to have any real effect unless the
option is selected, but there are a few changes to linker
script which must be causing it.

There are two changes to vmlinux.lds.h. One is to KEEP a
few input sections, that *should* be kept anyway. The other
is to bring in additional sections into their correct output
section.

Could you try reverting those lines of vmlinux.lds.h that
change the latter, i.e.:

- *(.text.hot .text .text.fixup .text.unlikely) \
+ *(.text.hot .text .text.fixup .text.unlikely .text.*) \

This is the culprit. After removing " .text.*" it builds fine.

Thanks for testing it. Some architectures have .text.x sections
not included here, I should have seen that. We should possibly
just revert that line and require implementing archs to do the
right thing.

I would call the build failure a regression, so it should either be
reverted, or we'll need some other solution to fix the build failure.

Thanks,
Guenter

[ Convention is to use '.' to avoid C identifiers, so we should
use .text..x for these things. But that's not done completely
throughout the kernel, and a little invasive to do with this
series. I'll revisit this and clean things up subsequently after
this round gets merged. ]

Thanks,
Nick