Hi Yann, Le 23/08/2019 à 16:39, Yann Sionneau a écrit : > Can you post the result of > > or1k-buildroot-linux-uclibc-readelf -W --relocs or1k_clone.os
Relocation section '.rela.text' at offset 0x158 contains 3 entries: Offset Info Type Sym. Value Symbol's Name + Addend 00000070 00000506 R_OR1K_INSN_REL_26 00000000 __GI__exit + 0 00000078 00000606 R_OR1K_INSN_REL_26 00000000 __syscall_error + 0 00000080 00000606 R_OR1K_INSN_REL_26 00000000 __syscall_error + 0 > > in the case which does not work (binutils 2.32 and modern GCC) and in the case > which does work (older toolchain?) The result is actually the same result for the two toolchains, the or1k_clone.os is the same (diff). > > Putting the binaries somewhere can also help. You can reproduce easily by using Buildroot from master branch and reverting the patch : https://git.buildroot.net/buildroot/commit/?id=295307700b49bada3f6e638716f00dd418a71b04 Then load the the Buildroot defconfig qemu_or1k_defconfig and build the toolchain. > > 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 ? I'll take a look. > > 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? I can build a toolchain using musl and using with Qemu a linux system generated by this toolchain. So, musl is not broken when using the new toolchain (gcc 9.1, binutils 2.32 and musl 1.1.23. > > Good luck! Thanks, Best regards, Romain > > Regards, > > Yann > > 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 >> /opt/openrisc--uclibc--bleeding-edge-1/lib/gcc/or1k-buildroot-linux-uclibc/9.2.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: >> >> libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol >> __syscall_error >> >> See: >> https://gitlab.com/kubu93/toolchains-builder/-/jobs/270854456 >> >> This error message come from a new check in binutils 2.32.x: >> >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f2c1801f6255a3f9f483ae2f07c7d7da0ddae4af >> >> >> 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. >> >> https://git.buildroot.net/buildroot/commit/?id=da70a55a1955ff673e0110bacb3daef50f21b29e >> >> >> 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, >> Romain >> >> _______________________________________________ >> devel mailing list >> [email protected] >> https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
