Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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.

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

----- 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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

----- 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.

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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.

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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.

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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.

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Alan Modra]

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

Re: Binutils 2.28 on PowerPC: dangerous relocation: generic linker can't handle R_PPC_SECTOFF_HA

[Sebastian Huber]

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.