Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
On Tue, Mar 2, 2021 at 9:28 PM Helge Deller wrote:
> * Helge Deller :
> > On 3/2/21 7:07 PM, Nick Desaulniers wrote:
> > > + Arnd
> > >
> > > On Tue, Mar 2, 2021 at 10:03 AM Helge Deller wrote:
> > > >
> > > >
> From: Helge Deller
> 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
> Reported-by: kernel test robot
> Fixes: 00e35f2b0e8a ("parisc: Enable -mlong-calls gcc option by default when
> !CONFIG_MODULES")
> Cc: sta...@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
Looks good to me, we should probably do something similar on arm with
CONFIG_{ARM,ARM64}_MODULE_PLTS, though that only affects loadable
modules, as the linker would insert its own trampolines during the final
link when branch relocations are out of range.
Arnd
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
* Helge Deller : > On 3/2/21 7:07 PM, Nick Desaulniers wrote: > > + Arnd > > > > On Tue, Mar 2, 2021 at 10:03 AM Helge Deller 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 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 > > > > > > > > > > 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 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
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
On 3/2/21 7:07 PM, Nick Desaulniers wrote: + Arnd On Tue, Mar 2, 2021 at 10:03 AM Helge Deller 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 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 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. Helge The better long-term solution is to add long branch stub support to the linker. Agreed. Helge The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) doesn't reorder existing sections, but does add .text.hot.* before TEXT_MAIN. Existing sections could have been placed as "orphan sections." 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 hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk init/main.o: in function `xbc_make_cmdline': (.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk (.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk init/main.o: in function `initcall_blacklist': (.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xbf8): cannot reach panic (.init.text+0xbf8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `panic'
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
+ Arnd On Tue, Mar 2, 2021 at 10:03 AM Helge Deller 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 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 > >> > >> 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? > > The better long-term solution is to add long branch stub support > to the linker. Agreed. > > Helge > > > The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) > > doesn't reorder existing sections, but does add .text.hot.* before > > TEXT_MAIN. Existing sections could have been placed as "orphan > > sections." > > > >> 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 > >> hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk > >> init/main.o: in function `xbc_make_cmdline': > >> (.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F > >> against symbol `printk' defined in .text.unlikely section in > >> kernel/printk/printk.o > >> hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk > >> (.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F > >> against symbol `printk' defined in .text.unlikely section in > >> kernel/printk/printk.o > >> hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk > >> init/main.o: in function `initcall_blacklist': > >> (.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F > >> against symbol `printk' defined in .text.unlikely section in > >> kernel/printk/printk.o > >> hppa64-linux-ld:
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
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 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 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). The better long-term solution is to add long branch stub support to the linker. Helge The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) doesn't reorder existing sections, but does add .text.hot.* before TEXT_MAIN. Existing sections could have been placed as "orphan sections." 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 hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk init/main.o: in function `xbc_make_cmdline': (.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk (.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk init/main.o: in function `initcall_blacklist': (.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F against symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o hppa64-linux-ld: init/main.o(.init.text+0xbf8): cannot reach panic (.init.text+0xbf8): relocation truncated to fit: R_PARISC_PCREL22F against symbol `panic' defined in .text.unlikely section in kernel/panic.o hppa64-linux-ld: init/main.o(.init.text+0xda0): cannot reach rest_init init/main.o: in function `arch_call_rest_init': (.init.text+0xda0): relocation truncated to fit: R_PARISC_PCREL22F against symbol `rest_init' defined in .ref.text section in init/main.o hppa64-linux-ld: init/main.o(.init.text+0xef4): cannot reach printk init/main.o: in
Re: hppa64-linux-ld: kernel/sched/core.o(.init.text+0x90): cannot reach printk
+ pa-risc folks On Tue, Mar 2, 2021 at 2:59 AM kernel test robot 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. > date: 6 months ago > config: parisc-randconfig-s031-20210228 (attached as .config) ^ randconfig (always find something curious) > 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 > > 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. If the linker is warning that printk is in the .text.unlikely section, I'm curious why printk is marked cold? Likely the randconfig produces a large TEXT_MAIN; 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. 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. The commit in question (eff8728fe69880d3f7983bec3fb6cea4c306261f) doesn't reorder existing sections, but does add .text.hot.* before TEXT_MAIN. Existing sections could have been placed as "orphan sections." >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 >hppa64-linux-ld: init/main.o(.init.text+0xa68): cannot reach printk >init/main.o: in function `xbc_make_cmdline': >(.init.text+0xa68): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0xaac): cannot reach printk >(.init.text+0xaac): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0xb68): cannot reach printk >init/main.o: in function `initcall_blacklist': >(.init.text+0xb68): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0xbf8): cannot reach panic >(.init.text+0xbf8): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `panic' defined in .text.unlikely section in kernel/panic.o >hppa64-linux-ld: init/main.o(.init.text+0xda0): cannot reach rest_init >init/main.o: in function `arch_call_rest_init': >(.init.text+0xda0): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `rest_init' defined in .ref.text section in init/main.o >hppa64-linux-ld: init/main.o(.init.text+0xef4): cannot reach printk >init/main.o: in function `start_kernel': >(.init.text+0xef4): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0xf84): cannot reach printk >(.init.text+0xf84): relocation truncated to fit: R_PARISC_PCREL22F against > symbol `printk' defined in .text.unlikely section in kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0x1068): cannot reach printk >(.init.text+0x1068): relocation truncated to fit: R_PARISC_PCREL22F > against symbol `printk' defined in .text.unlikely section in > kernel/printk/printk.o >hppa64-linux-ld: init/main.o(.init.text+0x10c4):
