[uclibc-ng-devel] [ork1] issue with Binutils 2.32 and gcc 9.x
yann at sionneau.net
Fri Aug 23 16:39:32 CEST 2019
Can you post the result of
or1k-buildroot-linux-uclibc-readelf -W --relocs or1k_clone.os
in the case which does not work (binutils 2.32 and modern GCC) and in the case which does work (older toolchain?)
Putting the binaries somewhere can also help.
It seems the issue arises from the relocation that the assembler generates when assembling this line : https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/or1k/or1k_clone.S#n74
It seems l.j followed with a global symbol used to work, but now it does not anymore?
Maybe try to decompose it with loading the symbol value in a register with hi() and lo() assembler directives and use l.jr rXX ?
This seems weird anyway since I can see the same kind of code in musl libc: https://elixir.bootlin.com/musl/latest/source/arch/or1k/crt_arch.h#L16 or is musl also broken with new toolchain?
On 8/16/19 7:35 PM, Romain Naour wrote:
> Hi Waldemar,
> I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.
> LD libuClibc-1.0.31.so
> libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol
> This error message come from a new check in binutils 2.32.x:
> With binutils 2.30.x and 2.31.x, I have another assembler error:
> Error: junk at end of line `l.movhi r17,gotoffha(.LC0)'
> ork1 support was added to gcc 9.x and enabled into Buildroot recently.
> I remember doing a test with qemu_or1k_defconfig before gcc 9.1 was released but
> I don't remember if it was with musl or uClibc-ng... It should be with uClibc-ng
> but I didn't trigged such error.
> Thoughts ?
> Best regards,
> devel mailing list
> devel at uclibc-ng.org
More information about the devel