* Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
@ 2017-06-01 10:07 Sebastian Huber
2017-06-01 10:42 ` Alan Modra
0 siblings, 1 reply; 14+ messages in thread
From: Sebastian Huber @ 2017-06-01 10:07 UTC (permalink / raw)
To: binutils
Hello,
I get the following errors using Binutils 2.28 on PowerPC for a bootloader program that is supposed to load an application image:
powerpc-rtems4.12-ld -o capture.ralf bootloader.o --just-symbols=capture.exe -b binary rtems.gz -T ppcboot.lds
bootloader.o: In function `start':
head.S:140:(.text+0x8a): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
head.S:141:(.text+0x8e): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
head.S:157:(.text+0xb2): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
head.S:159:(.text+0xba): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
bootloader.o: In function `moved':
head.S:182:(.text+0xf2): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
head.S:229:(.text+0x152): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
head.S:230:(.text+0x156): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
head.S:257:(.text+0x16e): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
head.S:259:(.text+0x176): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA
head.S:261:(.text+0x17e): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
head.S:262:(.text+0x182): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
bootloader.o: In function `reloc':
head.S:316:(.text+0x1de): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
head.S:330:(.text+0x206): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_LO
bootloader.o: In function `exit':
misc.c:68:(.text.exit+0x28): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
bootloader.o: In function `zfree':
misc.c:101:(.text.zfree+0x14): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
bootloader.o: In function `zalloc':
misc.c:91:(.text.zalloc+0x2c): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:94:(.text.zalloc+0x58): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
bootloader.o: In function `hang':
misc.c:78:(.text.hang+0x44): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:83:(.text.hang+0x6c): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
bootloader.o: In function `gunzip':
misc.c:141:(.text.gunzip+0xf4): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:150:(.text.gunzip+0x124): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:156:(.text.gunzip+0x144): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:121:(.text.gunzip+0x194): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:152:(.text.gunzip+0x1a0): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:143:(.text.gunzip+0x1ac): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
misc.c:135:(.text.gunzip+0x1b8): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
bootloader.o: In function `decompress_kernel':
misc.c:171:(.text.decompress_kernel+0x50): dangerous relocation: generic linker can't handle R_PPC_PLTREL24
This error is not present on the Git master of Binutils. A Git bisect revealed this:
3ce512885ba76da53fae84cd1a555bc721fdd25e is the first bad commit
commit 3ce512885ba76da53fae84cd1a555bc721fdd25e
Author: Alan Modra <amodra@gmail.com>
Date: Wed Jul 20 10:33:14 2016 +0930
Mark some more powerpc relocs as not handled by generic linker
* elf64-ppc.c (ppc64_elf_howto_raw <R_PPC64_PLTREL32>): Put
ppc64_elf_unhandled_reloc for special_function.
* elf32-ppc.c (ppc_elf_howto_raw): Similarly for lots of relocs.
:040000 040000 14d4373b29d8869d265ad3cce13a3bf7c3c9b604 b3178f48ebaad5f02515811ad7bab72cd046716b M bfd
I am now a bit unsure if this is an error in Binutils or our use of Binutils. If it was an error, how was it fixed in the meantime?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : [ http://lists.rtems.org/mailman/listinfo/devel | sebastian.huber at embedded-brains.de ] PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2017-06-01 10:07 Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA Sebastian Huber @ 2017-06-01 10:42 ` Alan Modra 2017-06-01 10:58 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2017-06-01 10:42 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Thu, Jun 01, 2017 at 12:07:54PM +0200, Sebastian Huber wrote: > Hello, > > I get the following errors using Binutils 2.28 on PowerPC for a bootloader program that is supposed to load an application image: > > powerpc-rtems4.12-ld -o capture.ralf bootloader.o --just-symbols=capture.exe -b binary rtems.gz -T ppcboot.lds > bootloader.o: In function `start': > head.S:140:(.text+0x8a): dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA Did you build the linker for the correct target? "generic linker" errors usually mean you're attempting to produce different output to the input objects. > This error is not present on the Git master of Binutils. You'll probably get the same if you misconfigure master. ;-) -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2017-06-01 10:42 ` Alan Modra @ 2017-06-01 10:58 ` Sebastian Huber 2017-06-01 11:07 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2017-06-01 10:58 UTC (permalink / raw) To: Alan Modra; +Cc: binutils Hello Alan, ----- Am 1. Jun 2017 um 12:42 schrieb Alan Modra amodra@gmail.com: > On Thu, Jun 01, 2017 at 12:07:54PM +0200, Sebastian Huber wrote: >> Hello, >> >> I get the following errors using Binutils 2.28 on PowerPC for a bootloader >> program that is supposed to load an application image: >> >> powerpc-rtems4.12-ld -o capture.ralf bootloader.o --just-symbols=capture.exe -b >> binary rtems.gz -T ppcboot.lds >> bootloader.o: In function `start': >> head.S:140:(.text+0x8a): dangerous relocation: generic linker can't handle >> R_PPC_SECTOFF_HA > > Did you build the linker for the correct target? "generic linker" > errors usually mean you're attempting to produce different output to > the input objects. I use the same configure command line to build 2.28 and the master. For the Git bisect, I re-used the build tree in each step. I get always: powerpc-rtems4.12-ld --print-output-format elf32-powerpc ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2017-06-01 10:58 ` Sebastian Huber @ 2017-06-01 11:07 ` Sebastian Huber 2017-06-01 14:06 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2017-06-01 11:07 UTC (permalink / raw) To: Alan Modra; +Cc: binutils ----- Am 1. Jun 2017 um 12:58 schrieb Sebastian Huber sebastian.huber@embedded-brains.de: > Hello Alan, > > ----- Am 1. Jun 2017 um 12:42 schrieb Alan Modra amodra@gmail.com: > >> On Thu, Jun 01, 2017 at 12:07:54PM +0200, Sebastian Huber wrote: >>> Hello, >>> >>> I get the following errors using Binutils 2.28 on PowerPC for a bootloader >>> program that is supposed to load an application image: >>> >>> powerpc-rtems4.12-ld -o capture.ralf bootloader.o --just-symbols=capture.exe -b >>> binary rtems.gz -T ppcboot.lds >>> bootloader.o: In function `start': >>> head.S:140:(.text+0x8a): dangerous relocation: generic linker can't handle >>> R_PPC_SECTOFF_HA >> >> Did you build the linker for the correct target? "generic linker" >> errors usually mean you're attempting to produce different output to >> the input objects. > > I use the same configure command line to build 2.28 and the master. For the Git > bisect, I re-used the build tree in each step. > > I get always: > > powerpc-rtems4.12-ld --print-output-format > elf32-powerpc Sorry, I made a mistake with the Git bisect. It doesn't work on the master. So, there must be indeed some configuration error on my side. How can I end up with a generic linker? I use this configure command line: ../binutils-git/configure --prefix=/opt/rtems-4.12 --target=powerpc-rtems4.12 '' --enable-deterministic-archives --disable-nls --disable-werror --disable-gdb --disable-libdecnumber --disable-readline --disable-sim ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2017-06-01 11:07 ` Sebastian Huber @ 2017-06-01 14:06 ` Alan Modra 2017-06-02 5:19 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2017-06-01 14:06 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Thu, Jun 01, 2017 at 01:08:02PM +0200, Sebastian Huber wrote: > How can I end up with a generic linker? One way is when producing srec or binary output. Like I said, a different output format to the input object files. Perhaps you have a wrong OUTPUT_FORMAT in the script? -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2017-06-01 14:06 ` Alan Modra @ 2017-06-02 5:19 ` Sebastian Huber [not found] ` <9a27522e-6a4e-ed0b-3ac4-cb30c027268d@embedded-brains.de> 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2017-06-02 5:19 UTC (permalink / raw) To: Alan Modra; +Cc: binutils ----- Am 1. Jun 2017 um 16:06 schrieb Alan Modra amodra@gmail.com: > On Thu, Jun 01, 2017 at 01:08:02PM +0200, Sebastian Huber wrote: >> How can I end up with a generic linker? > > One way is when producing srec or binary output. Like I said, a > different output format to the input object files. Perhaps you have > a wrong OUTPUT_FORMAT in the script? Thanks a lot for this hint. Someone commented out the OUTPUT_FORMAT() 17 years ago. I fixed this and got: ld: Warning: ticker.exe uses hard float, ticker.ralf uses soft float ld: ticker.exe: compiled normally and linked with modules compiled with -mrelocatable ld: failed to merge target specific data of file ticker.exe I added --no-warn-mismatch and now I have the bootloader again with Binutils 2.28. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <9a27522e-6a4e-ed0b-3ac4-cb30c027268d@embedded-brains.de>]
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA [not found] ` <9a27522e-6a4e-ed0b-3ac4-cb30c027268d@embedded-brains.de> @ 2019-05-08 8:42 ` Alan Modra 2019-05-14 12:42 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2019-05-08 8:42 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Tue, May 07, 2019 at 10:30:40AM +0200, Sebastian Huber wrote: > powerpc-rtems4.9-ld --version > GNU ld (GNU Binutils) 2.19.1 > > With this LD version I can boot the application. The LD output is a binary > file. I had to remove the OUTPUT_ARCH(powerpc) from ppcboot.lds. > > Since at least Binutils 2.28, it no longer works: > > powerpc-rtems5-ld -o ticker.ralf > /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o > --just-symbols=ticker.exe -b binary rtems.gz -T > ~/git-rtems-5/./bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds > /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o: in function > `start': > /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../../../../../bsps/powerpc/motorola_powerpc/bootloader/head.S:140:(.text+0x8a): > dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA > /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../../../../../bsps/powerpc/motorola_powerpc/bootloader/head.S:141:(.text+0x8e): The truth is that linking to binary with 2.19 did not handle any of the R_PPC_SECTOFF relocations correctly. They were handled just like the corresponding R_PPC_ADDR16 reloc, a fact that you can verify by comparing the reloc howtos. (Reloc howtos are used by the generic linker to apply relocations. When linking to powerpc ELF you'll be using the code in ppc_elf_relocate_section instead.) So the values applied by 2.19 were symbol values rather than symbol values relative to their output section. I think that means your assembly code has compensated for the 2.19 linker behaviour by some means or other, and therefore crashes with a fixed linker. You'll probably find that using 2.19 to link to ELF then objcopy to binary will also give you a "bad" output. [snip] > powerpc-rtems5-ld -o ticker.ralf > /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o > --just-symbols=ticker.exe -b binary rtems.gz -T > ~/git-rtems-5/./bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds > powerpc-rtems5-ld: ticker.exe uses hard float, > /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o uses soft > float > powerpc-rtems5-ld: failed to merge target specific data of file ticker.exe I guess you could argue that it's a bug to complain about --just-symbols target specific data. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-08 8:42 ` Alan Modra @ 2019-05-14 12:42 ` Sebastian Huber 2019-05-15 4:10 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2019-05-14 12:42 UTC (permalink / raw) To: Alan Modra; +Cc: binutils On 08/05/2019 10:41, Alan Modra wrote: > On Tue, May 07, 2019 at 10:30:40AM +0200, Sebastian Huber wrote: >> powerpc-rtems4.9-ld --version >> GNU ld (GNU Binutils) 2.19.1 >> >> With this LD version I can boot the application. The LD output is a binary >> file. I had to remove the OUTPUT_ARCH(powerpc) from ppcboot.lds. >> >> Since at least Binutils 2.28, it no longer works: >> >> powerpc-rtems5-ld -o ticker.ralf >> /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o >> --just-symbols=ticker.exe -b binary rtems.gz -T >> ~/git-rtems-5/./bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds >> /build/git-build/b-any/powerpc-rtems5/mvme2100/lib/bootloader.o: in function >> `start': >> /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../../../../../bsps/powerpc/motorola_powerpc/bootloader/head.S:140:(.text+0x8a): >> dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA >> /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../../../../../bsps/powerpc/motorola_powerpc/bootloader/head.S:141:(.text+0x8e): > The truth is that linking to binary with 2.19 did not handle any of > the R_PPC_SECTOFF relocations correctly. They were handled just like > the corresponding R_PPC_ADDR16 reloc, a fact that you can verify by > comparing the reloc howtos. (Reloc howtos are used by the generic > linker to apply relocations. When linking to powerpc ELF you'll be > using the code in ppc_elf_relocate_section instead.) So the values > applied by 2.19 were symbol values rather than symbol values relative > to their output section. > > I think that means your assembly code has compensated for the 2.19 > linker behaviour by some means or other, and therefore crashes with a > fixed linker. > > You'll probably find that using 2.19 to link to ELF then objcopy to > binary will also give you a "bad" output. Lets look at the following assembler code in the .text input section: https://git.rtems.org/rtems/tree/bsps/powerpc/motorola_powerpc/bootloader/head.S /* Call the routine to fill boot_data structure from residual data. * And to find where the code has to be moved. */ lis r3,__size@sectoff@ha addi r3,r3,__size@sectoff@l This symbol is defined by the linker script: https://git.rtems.org/rtems/tree/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds |.bss : { *(.sbss) *(.bss) . = ALIGN(4); } __bss_words = SIZEOF(.bss)>>2; __size = . ; /DISCARD/ : { *(.comment) } }| I built the latest Binutils and invoked ld in GDB. I set a break point to _bfd_final_link_relocate(). Here I get this: Breakpoint 1 at 0x44c590: file /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c, line 1340. (gdb) r Starting program: /opt/rtems/5/bin/powerpc-rtems5-ld -o ticker.ralf bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch Breakpoint 1, _bfd_final_link_relocate (howto=howto@entry=0x647340 <ppc_elf_howto_raw+1440>, input_bfd=input_bfd@entry=0x8a9c50, input_section=input_section@entry=0x8aae30, contents=contents@entry=0x99b5e0 "H", address=138, value=value@entry=155668, addend=18446744073709433152) at /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c:1340 1340 bfd_vma value, (gdb) bt #0 _bfd_final_link_relocate (howto=howto@entry=0x647340 <ppc_elf_howto_raw+1440>, input_bfd=input_bfd@entry=0x8a9c50, input_section=input_section@entry=0x8aae30, contents=contents@entry=0x99b5e0 "H", address=138, value=value@entry=155668, addend=18446744073709433152) at /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c:1340 #1 0x000000000045e54d in ppc_elf_relocate_section (output_bfd=output_bfd@entry=0x89d220, info=0x88c820 <link_info>, input_bfd=input_bfd@entry=0x8a9c50, input_section=input_section@entry=0x8aae30, contents=0x99b5e0 "H", relocs=relocs@entry=0x8d11d8, local_syms=0x9c5890, local_sections=0x9cdec0) at /home/EB/sebastian_h/archive/binutils-git/bfd/elf32-ppc.c:9039 #2 0x0000000000487029 in elf_link_input_bfd (flinfo=flinfo@entry=0x7fffffffd540, input_bfd=input_bfd@entry=0x8a9c50) at /home/EB/sebastian_h/archive/binutils-git/bfd/elflink.c:10887 #3 0x0000000000488897 in bfd_elf_final_link (abfd=<optimized out>, info=<optimized out>) at /home/EB/sebastian_h/archive/binutils-git/bfd/elflink.c:12214 #4 0x000000000041874d in ldwrite () at /home/EB/sebastian_h/archive/binutils-git/ld/ldwrite.c:581 #5 0x0000000000402f20 in main (argc=<optimized out>, argv=<optimized out>) at /home/EB/sebastian_h/archive/binutils-git/ld/ldmain.c:457 (gdb) frame 1 #1 0x000000000045e54d in ppc_elf_relocate_section (output_bfd=output_bfd@entry=0x89d220, info=0x88c820 <link_info>, input_bfd=input_bfd@entry=0x8a9c50, input_section=input_section@entry=0x8aae30, contents=0x99b5e0 "H", relocs=relocs@entry=0x8d11d8, local_syms=0x9c5890, local_sections=0x9cdec0) at /home/EB/sebastian_h/archive/binutils-git/bfd/elf32-ppc.c:9039 9039 r = _bfd_final_link_relocate (howto, input_bfd, input_section, contents, (gdb) p sym_name $1 = 0x8d4231 "__size" (gdb) p sec->output_section ->name $2 = 0x89cc60 ".bss" (gdb) p input_section->name $3 = 0x8b2c50 ".text" Why is the output section .bss for __size and not *ABS*? If I do this with the latest Binutils 2.19 branch. I get: (gdb) b _bfd_final_link_relocate Breakpoint 1 at 0x427b40: file /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c, line 1346. (gdb) r Starting program: /opt/rtems/4.9/bin/powerpc-rtems4.9-ld -o ticker.ralf bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch Breakpoint 1, _bfd_final_link_relocate (howto=howto@entry=0x4dcfe0 <ppc_elf_howto_raw+2880>, input_bfd=input_bfd@entry=0x7298e0, input_section=input_section@entry=0x72cdc8, contents=contents@entry=0x822e90 "H", address=138, value=value@entry=155668, addend=32768) at /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c:1346 1346 if (address > bfd_get_section_limit (input_bfd, input_section)) (gdb) bt #0 _bfd_final_link_relocate (howto=howto@entry=0x4dcfe0 <ppc_elf_howto_raw+2880>, input_bfd=input_bfd@entry=0x7298e0, input_section=input_section@entry=0x72cdc8, contents=contents@entry=0x822e90 "H", address=138, value=value@entry=155668, addend=32768) at /home/EB/sebastian_h/archive/binutils-git/bfd/reloc.c:1346 #1 0x000000000043a1ba in ppc_elf_relocate_section (output_bfd=output_bfd@entry=0x71d2c0, info=0x70f900 <link_info>, input_bfd=input_bfd@entry=0x7298e0, input_section=input_section@entry=0x72cdc8, contents=contents@entry=0x822e90 "H", relocs=relocs@entry=0x757d88, local_syms=0x84d140, local_sections=0x855770) at /home/EB/sebastian_h/archive/binutils-git/bfd/elf32-ppc.c:7318 #2 0x000000000045c359 in elf_link_input_bfd (finfo=finfo@entry=0x7fffffffd520, input_bfd=input_bfd@entry=0x7298e0) at /home/EB/sebastian_h/archive/binutils-git/bfd/elflink.c:9308 #3 0x000000000045df3e in bfd_elf_final_link (abfd=0x71d2c0, info=0x70f900 <link_info>) at /home/EB/sebastian_h/archive/binutils-git/bfd/elflink.c:10448 #4 0x000000000041534d in ldwrite () at /home/EB/sebastian_h/archive/binutils-git/ld/ldwrite.c:567 #5 0x000000000040283e in main (argc=<optimized out>, argv=<optimized out>) at /home/EB/sebastian_h/archive/binutils-git/ld/ldmain.c:462 (gdb) frame 1 #1 0x000000000043a1ba in ppc_elf_relocate_section (output_bfd=output_bfd@entry=0x71d2c0, info=0x70f900 <link_info>, input_bfd=input_bfd@entry=0x7298e0, input_section=input_section@entry=0x72cdc8, contents=contents@entry=0x822e90 "H", relocs=relocs@entry=0x757d88, local_syms=0x84d140, local_sections=0x855770) at /home/EB/sebastian_h/archive/binutils-git/bfd/elf32-ppc.c:7318 7318 r = _bfd_final_link_relocate (howto, (gdb) p sym_name $1 = 0x75aaa1 "__size" (gdb) p sec->output_section ->name $2 = 0x4acd54 "*ABS*" (gdb) p input_section ->name $3 = 0x73b770 ".text" -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-14 12:42 ` Sebastian Huber @ 2019-05-15 4:10 ` Alan Modra 2019-05-16 9:29 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2019-05-15 4:10 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Tue, May 14, 2019 at 02:42:36PM +0200, Sebastian Huber wrote: > Lets look at the following assembler code in the .text input section: > > https://git.rtems.org/rtems/tree/bsps/powerpc/motorola_powerpc/bootloader/head.S > > /* Call the routine to fill boot_data structure from residual data. >  * And to find where the code has to be moved. >  */ >    lis   r3,__size@sectoff@ha >    addi   r3,r3,__size@sectoff@l > > This symbol is defined by the linker script: > > https://git.rtems.org/rtems/tree/bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds > > |.bss : { *(.sbss) *(.bss) . = ALIGN(4); } __bss_words = SIZEOF(.bss)>>2; > __size = . ; /DISCARD/ : { *(.comment) } }| > > > I built the latest Binutils and invoked ld in GDB. I set a break point to > _bfd_final_link_relocate(). Here I get this: [snip] > (gdb) p sec->output_section ->name > $2 = 0x89cc60 ".bss" > > Why is the output section .bss for __size and not *ABS*? See ldexp.c set_sym_sections and ldlang.c section_for_dot. The linker ties assignments to their nearest output section statement because that works out best in most real-world usage. For example, symbols like "_end" should not be SHN_ABS due to their use in position independent code invariably wanting the value relocated by the base address of the shared library or PIE. We do have a way of forcing SHN_ABS symbols in scripts: __size = ABSOLUTE (.); > If I do this with the latest Binutils 2.19 branch. I get: [snip] > (gdb) p sec->output_section ->name > $2 = 0x4acd54 "*ABS*" Yes, well, this is why many ld.so implementations must relocate SHN_ABS symbols. Weird but necessary given older linker behaviour. The source you show is slightly crazy too. Why use @sectoff when expecting a SHN_ABS symbol? -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-15 4:10 ` Alan Modra @ 2019-05-16 9:29 ` Sebastian Huber 2019-05-16 14:05 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2019-05-16 9:29 UTC (permalink / raw) To: Alan Modra; +Cc: binutils On 15/05/2019 06:09, Alan Modra wrote: > The source you show is slightly crazy too. Why use @sectoff when > expecting a SHN_ABS symbol? It seems the bootloader must be relocatable. What would be the proper way to work with absolute addresses? Store them in global variables which contain a abs@fixup relocation? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-16 9:29 ` Sebastian Huber @ 2019-05-16 14:05 ` Alan Modra 2019-05-17 5:20 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2019-05-16 14:05 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Thu, May 16, 2019 at 11:29:48AM +0200, Sebastian Huber wrote: > On 15/05/2019 06:09, Alan Modra wrote: > > The source you show is slightly crazy too. Why use @sectoff when > > expecting a SHN_ABS symbol? > > It seems the bootloader must be relocatable. What would be the proper way to > work with absolute addresses? Store them in global variables which contain a > abs@fixup relocation? My point was that sym@sectoff@l and sym@sectoff@ha are exactly the same as sym@l and sym@ha respectively when sym is SHN_ABS. It's fine to use @sectoff with symbols for addresses within output sections, but symbols representing the size of multiple output sections really shouldn't be @sectoff. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-16 14:05 ` Alan Modra @ 2019-05-17 5:20 ` Sebastian Huber 2019-05-20 4:57 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Huber @ 2019-05-17 5:20 UTC (permalink / raw) To: Alan Modra; +Cc: binutils On 16/05/2019 16:05, Alan Modra wrote: > On Thu, May 16, 2019 at 11:29:48AM +0200, Sebastian Huber wrote: >> On 15/05/2019 06:09, Alan Modra wrote: >>> The source you show is slightly crazy too. Why use @sectoff when >>> expecting a SHN_ABS symbol? >> It seems the bootloader must be relocatable. What would be the proper way to >> work with absolute addresses? Store them in global variables which contain a >> abs@fixup relocation? > My point was that sym@sectoff@l and sym@sectoff@ha are exactly the > same as sym@l and sym@ha respectively when sym is SHN_ABS. It's fine > to use @sectoff with symbols for addresses within output sections, but > symbols representing the size of multiple output sections really > shouldn't be @sectoff. The problem is that if I change it to sym@ha and sym@l, then I get this assembler error: lis r3,__size@ha addi r3,r3,__size@l bsps/powerpc/motorola_powerpc/bootloader/head.S: Assembler messages: bsps/powerpc/motorola_powerpc/bootloader/head.S:151: Error: relocation cannot be done when using -mrelocatable bsps/powerpc/motorola_powerpc/bootloader/head.S:152: Error: relocation cannot be done when using -mrelocatable -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-17 5:20 ` Sebastian Huber @ 2019-05-20 4:57 ` Alan Modra 2019-05-27 8:43 ` Sebastian Huber 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2019-05-20 4:57 UTC (permalink / raw) To: Sebastian Huber; +Cc: binutils On Fri, May 17, 2019 at 07:20:39AM +0200, Sebastian Huber wrote: > On 16/05/2019 16:05, Alan Modra wrote: > > My point was that sym@sectoff@l and sym@sectoff@ha are exactly the > > same as sym@l and sym@ha respectively when sym is SHN_ABS. It's fine > > to use @sectoff with symbols for addresses within output sections, but > > symbols representing the size of multiple output sections really > > shouldn't be @sectoff. > > The problem is that if I change it to sym@ha and sym@l, then I get this > assembler error: > >    lis   r3,__size@ha >    addi   r3,r3,__size@l > > bsps/powerpc/motorola_powerpc/bootloader/head.S: Assembler messages: > bsps/powerpc/motorola_powerpc/bootloader/head.S:151: Error: relocation > cannot be done when using -mrelocatable > bsps/powerpc/motorola_powerpc/bootloader/head.S:152: Error: relocation > cannot be done when using -mrelocatable Hmm, that's the first I knew you were assembling with -mrelocatable (or noticed, if you said so). Oh well, that makes my comment about @sectoff wrong. Looks like you should continue using @sectoff and put __size = ABSOLUTE (.); in the script. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA 2019-05-20 4:57 ` Alan Modra @ 2019-05-27 8:43 ` Sebastian Huber 0 siblings, 0 replies; 14+ messages in thread From: Sebastian Huber @ 2019-05-27 8:43 UTC (permalink / raw) To: Alan Modra; +Cc: binutils Hello Alan, On 20/05/2019 06:57, Alan Modra wrote: > On Fri, May 17, 2019 at 07:20:39AM +0200, Sebastian Huber wrote: >> On 16/05/2019 16:05, Alan Modra wrote: >>> My point was that sym@sectoff@l and sym@sectoff@ha are exactly the >>> same as sym@l and sym@ha respectively when sym is SHN_ABS. It's fine >>> to use @sectoff with symbols for addresses within output sections, but >>> symbols representing the size of multiple output sections really >>> shouldn't be @sectoff. >> The problem is that if I change it to sym@ha and sym@l, then I get this >> assembler error: >> >> lis r3,__size@ha >> addi r3,r3,__size@l >> >> bsps/powerpc/motorola_powerpc/bootloader/head.S: Assembler messages: >> bsps/powerpc/motorola_powerpc/bootloader/head.S:151: Error: relocation >> cannot be done when using -mrelocatable >> bsps/powerpc/motorola_powerpc/bootloader/head.S:152: Error: relocation >> cannot be done when using -mrelocatable > Hmm, that's the first I knew you were assembling with -mrelocatable > (or noticed, if you said so). Oh well, that makes my comment about > @sectoff wrong. Looks like you should continue using @sectoff and > put __size = ABSOLUTE (.); in the script. thanks for your kind help and patience. It was quite easy to fix in the end: https://git.rtems.org/rtems/commit/?id=f419349a1370ffed9cb3d2322d01e801e012134e -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-05-27 8:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-01 10:07 Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA Sebastian Huber
2017-06-01 10:42 ` Alan Modra
2017-06-01 10:58 ` Sebastian Huber
2017-06-01 11:07 ` Sebastian Huber
2017-06-01 14:06 ` Alan Modra
2017-06-02 5:19 ` Sebastian Huber
[not found] ` <9a27522e-6a4e-ed0b-3ac4-cb30c027268d@embedded-brains.de>
2019-05-08 8:42 ` Alan Modra
2019-05-14 12:42 ` Sebastian Huber
2019-05-15 4:10 ` Alan Modra
2019-05-16 9:29 ` Sebastian Huber
2019-05-16 14:05 ` Alan Modra
2019-05-17 5:20 ` Sebastian Huber
2019-05-20 4:57 ` Alan Modra
2019-05-27 8:43 ` Sebastian Huber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).