All of lore.kernel.org
 help / color / mirror / Atom feed
* 4.14 git: massive linker failures: cannot reach anything
@ 2017-09-11 14:17 Meelis Roos
  2017-09-11 14:24 ` John David Anglin
  0 siblings, 1 reply; 5+ messages in thread
From: Meelis Roos @ 2017-09-11 14:17 UTC (permalink / raw)
  To: linux-parisc

While compiling 4.13+git on all of my gentoo parisc machines, I get tons 
of linking failures like below. 

$ ld -v
GNU ld (Gentoo 2.26.1 p1.0) 2.26.1

$ hppa64-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/hppa2.0-unknown-linux-gnu/hppa64-unknown-linux-gnu/gcc-bin/5.4.0/hppa64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa64-unknown-linux-gnu/5.4.0/lto-wrapper
Target: hppa64-unknown-linux-gnu
Configured with: 
/var/tmp/portage/sys-devel/kgcc64-5.4.0/work/gcc-5.4.0/configure 
--host=hppa2.0-unknown-linux-gnu --target=hppa64-unknown-linux-gnu 
--build=hppa2.0-unknown-linux-gnu --prefix=/usr 
--bindir=/usr/hppa2.0-unknown-linux-gnu/hppa64-unknown-linux-gnu/gcc-bin/5.4.0 
--includedir=/usr/lib/gcc/hppa64-unknown-linux-gnu/5.4.0/include 
--datadir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0 
--mandir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/man 
--infodir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/info 
--with-gxx-include-dir=/usr/lib/gcc/hppa64-unknown-linux-gnu/5.4.0/include/g++-v5 
--with-python-dir=/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/python 
--enable-languages=c --enable-obsolete --enable-secureplt 
--disable-werror --with-system-zlib --enable-nls 
--without-included-gettext --enable-checking=release 
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0 p1.0' 
--enable-poison-system-directories --disable-shared 
--disable-libatomic --disable-threads --without-headers 
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu 
--disable-multilib --disable-altivec --disable-fixed-point 
--disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp 
--disable-libquadmath --enable-lto --without-isl --disable-libsanitizer
Thread model: single
gcc version 5.4.0 (Gentoo 5.4.0 p1.0)

hppa64-linux-ld: init/main.o(.text+0x160): cannot reach strreplace
init/main.o: In function `initcall_blacklisted':(.text+0x160): relocation truncated to fit: R_PARISC_PCREL22F against symbol `strreplace' defined in .text.strreplace section in lib/string.o
hppa64-linux-ld: init/main.o(.text+0x1a4): cannot reach strcmp
init/main.o: In function `initcall_blacklisted':(.text+0x1a4): relocation truncated to fit: R_PARISC_PCREL22F against symbol `strcmp' defined in .text.strcmp section in lib/string.o
hppa64-linux-ld: init/main.o(.text+0x22c): cannot reach __ubsan_handle_type_mismatch
init/main.o: In function `initcall_blacklisted':(.text+0x22c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `__ubsan_handle_type_mismatch' defined in .text.__ubsan_handle_type_mismatch section in lib/ubsan.o

and so on for pages, more than my terminal scrollback provides.



-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 4.14 git: massive linker failures: cannot reach anything
  2017-09-11 14:17 4.14 git: massive linker failures: cannot reach anything Meelis Roos
@ 2017-09-11 14:24 ` John David Anglin
  2017-09-11 14:45   ` Meelis Roos
  0 siblings, 1 reply; 5+ messages in thread
From: John David Anglin @ 2017-09-11 14:24 UTC (permalink / raw)
  To: Meelis Roos, linux-parisc

On 2017-09-11 10:17 AM, Meelis Roos wrote:
> While compiling 4.13+git on all of my gentoo parisc machines, I get tons
> of linking failures like below.
>
> $ ld -v
> GNU ld (Gentoo 2.26.1 p1.0) 2.26.1
>
> $ hppa64-linux-gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/hppa2.0-unknown-linux-gnu/hppa64-unknown-linux-gnu/gcc-bin/5.4.0/hppa64-unknown-linux-gnu-gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa64-unknown-linux-gnu/5.4.0/lto-wrapper
> Target: hppa64-unknown-linux-gnu
> Configured with:
> /var/tmp/portage/sys-devel/kgcc64-5.4.0/work/gcc-5.4.0/configure
> --host=hppa2.0-unknown-linux-gnu --target=hppa64-unknown-linux-gnu
> --build=hppa2.0-unknown-linux-gnu --prefix=/usr
> --bindir=/usr/hppa2.0-unknown-linux-gnu/hppa64-unknown-linux-gnu/gcc-bin/5.4.0
> --includedir=/usr/lib/gcc/hppa64-unknown-linux-gnu/5.4.0/include
> --datadir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0
> --mandir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/man
> --infodir=/usr/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/info
> --with-gxx-include-dir=/usr/lib/gcc/hppa64-unknown-linux-gnu/5.4.0/include/g++-v5
> --with-python-dir=/share/gcc-data/hppa64-unknown-linux-gnu/5.4.0/python
> --enable-languages=c --enable-obsolete --enable-secureplt
> --disable-werror --with-system-zlib --enable-nls
> --without-included-gettext --enable-checking=release
> --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0 p1.0'
> --enable-poison-system-directories --disable-shared
> --disable-libatomic --disable-threads --without-headers
> --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
> --disable-multilib --disable-altivec --disable-fixed-point
> --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp
> --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer
> Thread model: single
> gcc version 5.4.0 (Gentoo 5.4.0 p1.0)
>
> hppa64-linux-ld: init/main.o(.text+0x160): cannot reach strreplace
> init/main.o: In function `initcall_blacklisted':(.text+0x160): relocation truncated to fit: R_PARISC_PCREL22F against symbol `strreplace' defined in .text.strreplace section in lib/string.o
> hppa64-linux-ld: init/main.o(.text+0x1a4): cannot reach strcmp
> init/main.o: In function `initcall_blacklisted':(.text+0x1a4): relocation truncated to fit: R_PARISC_PCREL22F against symbol `strcmp' defined in .text.strcmp section in lib/string.o
> hppa64-linux-ld: init/main.o(.text+0x22c): cannot reach __ubsan_handle_type_mismatch
> init/main.o: In function `initcall_blacklisted':(.text+0x22c): relocation truncated to fit: R_PARISC_PCREL22F against symbol `__ubsan_handle_type_mismatch' defined in .text.__ubsan_handle_type_mismatch section in lib/ubsan.o
>
> and so on for pages, more than my terminal scrollback provides.
As far as gcc goes, you need to add -mlong-calls to avoid these errors.  
I think there is a config option. The kernel is too big and some "b,l" 
branches can't reach their targets.

Dave

-- 
John David Anglin  dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 4.14 git: massive linker failures: cannot reach anything
  2017-09-11 14:24 ` John David Anglin
@ 2017-09-11 14:45   ` Meelis Roos
  2017-09-11 14:51     ` John David Anglin
  0 siblings, 1 reply; 5+ messages in thread
From: Meelis Roos @ 2017-09-11 14:45 UTC (permalink / raw)
  To: John David Anglin; +Cc: linux-parisc

> > hppa64-linux-ld: init/main.o(.text+0x22c): cannot reach
> > __ubsan_handle_type_mismatch
> > init/main.o: In function `initcall_blacklisted':(.text+0x22c): relocation
> > truncated to fit: R_PARISC_PCREL22F against symbol
> > `__ubsan_handle_type_mismatch' defined in .text.__ubsan_handle_type_mismatch
> > section in lib/ubsan.o
> > 
> > and so on for pages, more than my terminal scrollback provides.
> As far as gcc goes, you need to add -mlong-calls to avoid these errors.  I
> think there is a config option. The kernel is too big and some "b,l" branches
> can't reach their targets.

Thank you, yes, I found CONFIG_MLONGCALLS for that.

However, the next strange thing is why did custom kernels of multiple 
different machines grew so much (A500 UP and RP3440 SMP kernels)? My 
kernel configs are quite minimalistic anyway, except I include 
everything needed for booting (no dependenc on initramfs, so sd, scsi 
driver and ext4 are in). Perhaps a binary format or two, PDC stable 
storage and anothe IO schaduler too, and some kernel debugging options 
like UBSAN.

-- 
Meelis Roos (mroos@linux.ee)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 4.14 git: massive linker failures: cannot reach anything
  2017-09-11 14:45   ` Meelis Roos
@ 2017-09-11 14:51     ` John David Anglin
  2017-09-11 18:42       ` Helge Deller
  0 siblings, 1 reply; 5+ messages in thread
From: John David Anglin @ 2017-09-11 14:51 UTC (permalink / raw)
  To: Meelis Roos; +Cc: linux-parisc

On 2017-09-11 10:45 AM, Meelis Roos wrote:
>>> hppa64-linux-ld: init/main.o(.text+0x22c): cannot reach
>>> __ubsan_handle_type_mismatch
>>> init/main.o: In function `initcall_blacklisted':(.text+0x22c): relocation
>>> truncated to fit: R_PARISC_PCREL22F against symbol
>>> `__ubsan_handle_type_mismatch' defined in .text.__ubsan_handle_type_mismatch
>>> section in lib/ubsan.o
>>>
>>> and so on for pages, more than my terminal scrollback provides.
>> As far as gcc goes, you need to add -mlong-calls to avoid these errors.  I
>> think there is a config option. The kernel is too big and some "b,l" branches
>> can't reach their targets.
> Thank you, yes, I found CONFIG_MLONGCALLS for that.
>
> However, the next strange thing is why did custom kernels of multiple
> different machines grew so much (A500 UP and RP3440 SMP kernels)? My
> kernel configs are quite minimalistic anyway, except I include
> everything needed for booting (no dependenc on initramfs, so sd, scsi
> driver and ext4 are in). Perhaps a binary format or two, PDC stable
> storage and anothe IO schaduler too, and some kernel debugging options
> like UBSAN.
UBSAN is huge.  Helge knows more about it.  I would only use it for test 
kernels.

Dave

-- 
John David Anglin  dave.anglin@bell.net


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 4.14 git: massive linker failures: cannot reach anything
  2017-09-11 14:51     ` John David Anglin
@ 2017-09-11 18:42       ` Helge Deller
  0 siblings, 0 replies; 5+ messages in thread
From: Helge Deller @ 2017-09-11 18:42 UTC (permalink / raw)
  To: John David Anglin, Meelis Roos; +Cc: linux-parisc

On 11.09.2017 16:51, John David Anglin wrote:
> On 2017-09-11 10:45 AM, Meelis Roos wrote:
>>>> hppa64-linux-ld: init/main.o(.text+0x22c): cannot reach
>>>> __ubsan_handle_type_mismatch
>>>> init/main.o: In function `initcall_blacklisted':(.text+0x22c): relocation
>>>> truncated to fit: R_PARISC_PCREL22F against symbol
>>>> `__ubsan_handle_type_mismatch' defined in .text.__ubsan_handle_type_mismatch
>>>> section in lib/ubsan.o
>>>>
>>>> and so on for pages, more than my terminal scrollback provides.
>>> As far as gcc goes, you need to add -mlong-calls to avoid these errors.  I
>>> think there is a config option. The kernel is too big and some "b,l" branches
>>> can't reach their targets.
>> Thank you, yes, I found CONFIG_MLONGCALLS for that.
>>
>> However, the next strange thing is why did custom kernels of multiple
>> different machines grew so much (A500 UP and RP3440 SMP kernels)? My
>> kernel configs are quite minimalistic anyway, except I include
>> everything needed for booting (no dependenc on initramfs, so sd, scsi
>> driver and ext4 are in). Perhaps a binary format or two, PDC stable
>> storage and anothe IO schaduler too, and some kernel debugging options
>> like UBSAN.

> UBSAN is huge.

Yes, UBSAN is huge and is probably the reason why you see so many linker errors.
Beside enabling CONFIG_MLONGCALLS in the kernel, you probably need to
update palo [1] to version 1.99 as well. Please remember to update palo in the
boot sector on the harddisc too (run: "palo -v" once), otherwise
palo may refuse to load your kernel because of it's size (even if it's
compressed with gzip).

Helge

[1] https://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-09-11 18:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-11 14:17 4.14 git: massive linker failures: cannot reach anything Meelis Roos
2017-09-11 14:24 ` John David Anglin
2017-09-11 14:45   ` Meelis Roos
2017-09-11 14:51     ` John David Anglin
2017-09-11 18:42       ` Helge Deller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.