Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk

[Helge Deller <deller@gmx.de>]

* Helge Deller <deller@gmx.de>:
> On 3/2/21 7:07 PM, Nick Desaulniers wrote:
> > + Arnd
> >
> > On Tue, Mar 2, 2021 at 10:03 AM Helge Deller <deller@gmx.de> wrote:
> > >
> > > On 3/2/21 6:29 PM, Nick Desaulniers wrote:
> > > > + pa-risc folks
> > >
> > > Thanks for looking into this, Nick!
> > >
> > > > On Tue, Mar 2, 2021 at 2:59 AM kernel test robot <lkp@intel.com> wrote:
> > > > >
> > > > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > > > head:   7a7fd0de4a9804299793e564a555a49c1fc924cb
> > > > > commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and AutoFDO input sections
> > > >
> > > > This commit added sections explicitly to the kernel's linker script.
> > >
> > > Yes, but even when reverting this patch it does not prevent
> > > the linking problems.
> > >
> > >
> > > > > date:   6 months ago
> > > > > config: parisc-randconfig-s031-20210228 (attached as .config)
> > > >
> > > > ^ randconfig (always find something curious)
> > >
> > > Yes :-)
> > >
> > >
> > > > > compiler: hppa64-linux-gcc (GCC) 9.3.0
> > > > > reproduce:
> > > > >           wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > > >           chmod +x ~/bin/make.cross
> > > > >           # apt-get install sparse
> > > > >           # sparse version: v0.6.3-241-geaceeafa-dirty
> > > > >           # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f
> > > > >           git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > >           git fetch --no-tags linus master
> > > > >           git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f
> > > > >           # save the attached .config to linux build tree
> > > > >           COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc
> > > > >
> > > > > If you fix the issue, kindly add following tag as appropriate
> > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > >      hppa64-linux-ld: init/main.o(.init.text+0x294): cannot reach printk
> > > > >      init/main.o: in function `do_early_param':
> > > > >      (.init.text+0x294): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o
> > > >
> > > > ^ so we can't encode a jump to printk from do_early_param.
> > >
> > > Right.
> > >
> > > > If the linker is warning that printk is in the .text.unlikely
> > > > section, I'm curious why printk is marked cold?
> > >
> > > printk is always marked cold, see include/linux/printk.h:
> > > asmlinkage __printf(1, 2) __cold
> > > int printk(const char *fmt, ...);
> > >
> > > > Likely the randconfig produces a large TEXT_MAIN;
> > >
> > > Yes.
> > >
> > > > I'm guessing that .init.text is on one side of TEXT_MAIN, and
> > > > .text.unlikely is on the other.  Though there are many different
> > > > instances below.
> > > Yes. But even the large TEXT_MAIN by itself can become a problem.
> > >
> > > > I'm more familiar with ARM; it's common for the linker to insert
> > > > trampolines/thunks to bridge jumps too large to encode in a given
> > > > instruction.  I don't know if BFD has arch agnostic machinery for
> > > > that, but might be seeing if there's anything reuseable there.
> > >
> > > Dave mentioned in another mail, that long branch stub support is
> > > still missing in the 64-bit parisc linker.
> > >
> > > My question still remains:
> > > Is there any possibility to detect that we build/configure a
> > > 0-day kernel? If so, auto-enabling CONFIG_MLONGCALLS kernel option
> > > would solve it (temporarily).
> >
> > Arnd, is this kind of case what CONFIG_COMPILE_TEST is usually used for?
>
> Yes, I think that's the right knob!
> CONFIG_COMPILE_TEST is enabled on all parisc configs for which 0-day
> reported issues.
> I've wired it up in Kconfig and it now works around the issue.

I've committed the patch below to the parisc for-next tree, which allows
to monitor if this fixes the linkage problems...

Helge



From: Helge Deller <deller@gmx.de>
Date: Tue, 2 Mar 2021 21:07:07 +0100
Subject: [PATCH] parisc: Enable -mlong-calls gcc option with
 CONFIG_COMPILE_TEST

The kernel test robot reported multiple linkage problems like this:

    hppa64-linux-ld: init/main.o(.init.text+0x56c): cannot reach printk
    init/main.o: in function `unknown_bootoption':
    (.init.text+0x56c): relocation truncated to fit: R_PARISC_PCREL22F against
	symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o

There are two ways to solve it:
a) Enable the -mlong-call compiler option (CONFIG_MLONGCALLS),
b) Add long branch stub support in 64-bit linker.

While b) is the long-term solution, this patch works around the issue by
automatically enabling the CONFIG_MLONGCALLS option when
CONFIG_COMPILE_TEST is set, which indicates that a non-production kernel
(e.g. 0-day kernel) is built.

Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 00e35f2b0e8a ("parisc: Enable -mlong-calls gcc option by default when !CONFIG_MODULES")
Cc: stable@vger.kernel.org # v5.6+

diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 4e53ac46e857..afc3b8d03572 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -203,9 +203,12 @@ config PREFETCH
 	def_bool y
 	depends on PA8X00 || PA7200

+config PARISC_HUGE_KERNEL
+	def_bool y if !MODULES || UBSAN || FTRACE || COMPILE_TEST
+
 config MLONGCALLS
-	def_bool y if !MODULES || UBSAN || FTRACE
-	bool "Enable the -mlong-calls compiler option for big kernels" if MODULES && !UBSAN && !FTRACE
+	def_bool y if PARISC_HUGE_KERNEL
+	bool "Enable the -mlong-calls compiler option for big kernels" if !PARISC_HUGE_KERNEL
 	depends on PA8X00
 	help
 	  If you configure the kernel to include many drivers built-in instead