[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4bff2ed-26b4-29b7-e51a-ac5e5ece58a2@roeck-us.net>
Date: Tue, 13 Sep 2016 13:25:22 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Michal Marek <mmarek@...e.com>, Chen Liqin <liqin.linux@...il.com>,
Lennox Wu <lennox.wu@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Build failure in -next due to 'kbuild: allow archs to select link
dead code/data elimination'
On 09/12/2016 08:51 PM, Nicholas Piggin wrote:
> On Mon, 12 Sep 2016 20:17:30 -0700
> Guenter Roeck <linux@...ck-us.net> 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@...ck-us.net> 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
>
Powered by blists - more mailing lists