From: Guenter Roeck <linux@roeck-us.net>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Michal Marek <mmarek@suse.com>,
Chen Liqin <liqin.linux@gmail.com>,
Lennox Wu <lennox.wu@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'
Date: Wed, 14 Sep 2016 12:48:53 -0700 [thread overview]
Message-ID: <20160914194853.GB16397@roeck-us.net> (raw)
In-Reply-To: <20160914123004.624dd180@roar.ozlabs.ibm.com>
On Wed, Sep 14, 2016 at 12:30:04PM +1000, Nicholas Piggin wrote:
> On Tue, 13 Sep 2016 13:25:22 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
>
> > On 09/12/2016 08:51 PM, Nicholas Piggin wrote:
> > > On Mon, 12 Sep 2016 20:17:30 -0700
> > > Guenter Roeck <linux@roeck-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@roeck-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.
>
> Yes it's definitely a regression and that part should be reverted.
> To confirm, the following patch fixes your build?
>
> Thanks,
> Nick
>
> commit 0ae28be83b4d6cd03ef5b481487d042f2b91954e
> Author: Nicholas Piggin <npiggin@gmail.com>
> Date: Wed Sep 14 12:24:03 2016 +1000
>
> kbuild: -ffunction-sections fix for archs with conflicting sections
>
> Enabling -ffunction-sections modified the generic linker script to
> pull .text.* sections into regular TEXT_TEXT section, conflicting
> with some architectures. Revert that change and require archs that
> enable the option to ensure they have no conflicting section names,
> and do the appropriate merging.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>
Tested-by: Guenter Roeck <linux@roeck-us.net>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 6d5b631..8248037 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -487,7 +487,9 @@ config LD_DEAD_CODE_DATA_ELIMINATION
> This requires that the arch annotates or otherwise protects
> its external entry points from being discarded. Linker scripts
> must also merge .text.*, .data.*, and .bss.* correctly into
> - output sections.
> + output sections. Care must be taken not to pull in unrelated
> + sections (e.g., '.text.init'). Typically '.' in section names
> + is used to distinguish them from label names / C identifiers.
>
> config HAVE_CONTEXT_TRACKING
> bool
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index ad9d8f9..48dd44f 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -198,9 +198,9 @@
>
> /*
> * .data section
> - * -fdata-sections generates .data.identifier which needs to be pulled in
> - * with .data, but don't want to pull in .data..stuff which has its own
> - * requirements. Same for bss.
> + * LD_DEAD_CODE_DATA_ELIMINATION option enables -fdata-sections generates
> + * .data.identifier which needs to be pulled in with .data, but don't want to
> + * pull in .data..stuff which has its own requirements. Same for bss.
> */
> #define DATA_DATA \
> *(.data .data.[0-9a-zA-Z_]*) \
> @@ -434,10 +434,15 @@
> }
>
> /* .text section. Map to function alignment to avoid address changes
> - * during second ld run in second ld pass when generating System.map */
> + * during second ld run in second ld pass when generating System.map
> + * LD_DEAD_CODE_DATA_ELIMINATION option enables -ffunction-sections generates
> + * .text.identifier which needs to be pulled in with .text , but some
> + * architectures define .text.foo which is not intended to be pulled in here.
> + * Those enabling LD_DEAD_CODE_DATA_ELIMINATION must ensure they don't have
> + * conflicting section names, and must pull in .text.[0-9a-zA-Z_]* */
> #define TEXT_TEXT \
> ALIGN_FUNCTION(); \
> - *(.text.hot .text .text.fixup .text.unlikely .text.*) \
> + *(.text.hot .text .text.fixup .text.unlikely) \
> *(.ref.text) \
> MEM_KEEP(init.text) \
> MEM_KEEP(exit.text) \
next prev parent reply other threads:[~2016-09-14 19:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 22:24 Guenter Roeck
2016-09-13 2:00 ` Nicholas Piggin
2016-09-13 3:17 ` Guenter Roeck
2016-09-13 3:51 ` Nicholas Piggin
2016-09-13 20:25 ` Guenter Roeck
2016-09-14 2:30 ` Nicholas Piggin
2016-09-14 19:48 ` Guenter Roeck [this message]
2016-09-22 12:38 ` Michal Marek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160914194853.GB16397@roeck-us.net \
--to=linux@roeck-us.net \
--cc=lennox.wu@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liqin.linux@gmail.com \
--cc=mmarek@suse.com \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®