[ork1] issue with Binutils 2.32 and gcc 9.x

List overview All Threads
Download

newer

older

Potential bug with feof, fgetc,...

Using thread local storage on...

Romain Naour

16 Aug 2019 16 Aug '19

5:35 p.m.

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=f2c… 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=da70a55a1955ff673e0110bacb3d… 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

Show replies by thread

Stafford Horne

23 Aug 23 Aug

1:47 p.m.

On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour wrote:

...

Hi Waldemar, I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.

Hi Romain, Thank you for reporting and doing the initial investigation. Sorry, I haven't built uclibc-ng for a while. Have you been able to make much progress?

...

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=f2c…

Right, this patch added several new validations. I am guessing the complaint is correct and we need to fix something in uclibc-ng.

...

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=da70a55a1955ff673e0110bacb3d…

The above error comes because we need binutils 2.32.x with the new toolchain.

...

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 ?

It's likely the new validations added with binutils 2.32.x. I'll try to build uclibc-ng and see if I can reproduce. -Stafford

Yann Sionneau

2:39 p.m.

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/o… 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? Good luck! Regards, Yann On 8/16/19 7:35 PM, Romain Naour wrote:

...

Romain Naour

3:23 p.m.

Hi Stafford, Le 23/08/2019 à 15:47, Stafford Horne a écrit :

...

On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour wrote:

Hi Waldemar, I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.

Hi Romain, Thank you for reporting and doing the initial investigation. Sorry, I haven't built uclibc-ng for a while.

You're welcome, your help is very appreciated.

...

Have you been able to make much progress?

Yes and no...

...

Right, this patch added several new validations. I am guessing the complaint is correct and we need to fix something in uclibc-ng.

No, I haven't found a solution yet. sysdep.h was added by commit [1] that merge the clone() code from the glibc fork for or1k [2]. For now I disabled uClibc for or1k when building with gcc 9.x [3]. [1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=69ea4c1f65bff9… [2] https://github.com/openrisc/or1k-glibc/tree/master/ports/sysdeps/unix/sysv/… [3] https://git.buildroot.net/buildroot/commit/?id=295307700b49bada3f6e638716f0…

...

The above error comes because we need binutils 2.32.x with the new toolchain.

Indeed, I figured out that binutils >= 2.32 was mandatory to use gcc 9.1 [4]. [4] https://git.buildroot.net/buildroot/commit/?id=e0ba09768eb27872e86857549526…

...

It's likely the new validations added with binutils 2.32.x. I'll try to build uclibc-ng and see if I can reproduce.

You can reproduce easily by using Buildroot from master branch and reverting the patch [3]. I runtime tested the new or1k toolchain using musl libc by using the Buildroot defconfig qemu_or1k_defconfig. Best regards, Romain

...

-Stafford

Stafford Horne

9:01 p.m.

On Fri, Aug 23, 2019 at 05:23:12PM +0200, Romain Naour wrote:

...

Hi Stafford, Le 23/08/2019 à 15:47, Stafford Horne a écrit :

On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour wrote:

Hi Waldemar, I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.

Hi Romain, Thank you for reporting and doing the initial investigation. Sorry, I haven't built uclibc-ng for a while.

You're welcome, your help is very appreciated.

Have you been able to make much progress?

Yes and no...

I was able to reproduce the issue and did a temporary fix by just deleting the __syscall_error from or1k_clone.S (2 places). This fixed the build but probably not something we really want to do. But it does point out that the only bad symbol is the one in or1k_clone.S. There is a glibc port I am working on getting working right now: https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/unix/s… It seems to have the same code. But it does not have this problem. The macro for SYSCALL_ERROR_NAME is probably getting evaluated differently in glibc vs uclibc-ng. This fix should not be too hard. SYSCALL_ERROR_NAME is only being used on or1k_clone.S. Let's try to see what is the right thing to replace it with for uclibc-ng. -Stafford

Romain Naour

24 Aug 24 Aug

11:23 a.m.

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=295307700b49bada3f6e638716f0… 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/o… 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=f2c… > > > 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=da70a55a1955ff673e0110bacb3d… > > > 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 > devel(a)uclibc-ng.org > https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Romain Naour

12:45 p.m.

Hi Stafford, Le 23/08/2019 à 23:01, Stafford Horne a écrit :

...

On Fri, Aug 23, 2019 at 05:23:12PM +0200, Romain Naour wrote:

Hi Stafford, Le 23/08/2019 à 15:47, Stafford Horne a écrit :

On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour wrote:

Hi Waldemar, I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.

Hi Romain, Thank you for reporting and doing the initial investigation. Sorry, I haven't built uclibc-ng for a while.

You're welcome, your help is very appreciated.

Have you been able to make much progress?

Yes and no...

I don't get it, there is only SYSCALL_ERROR_NAME from or1k_clone.S. Maybe post the patch diff here.

...

There is a glibc port I am working on getting working right now: https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/unix/s… It seems to have the same code. But it does not have this problem. The macro for SYSCALL_ERROR_NAME is probably getting evaluated differently in glibc vs uclibc-ng.

Maybe something doesn't work with the way we define SYSCALL_ERROR_NAME https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/o…

...

This fix should not be too hard. SYSCALL_ERROR_NAME is only being used on or1k_clone.S. Let's try to see what is the right thing to replace it with for uclibc-ng.

I haven't looked in depth in the code, I'm not sure how to fix this :-/ Best regards, Romain

...

-Stafford

Stafford Horne

26 Aug 26 Aug

9:02 p.m.

On Sat, Aug 24, 2019 at 02:45:59PM +0200, Romain Naour wrote:

...

Hi Stafford, Le 23/08/2019 à 23:01, Stafford Horne a écrit :

On Fri, Aug 23, 2019 at 05:23:12PM +0200, Romain Naour wrote:

Hi Stafford, Le 23/08/2019 à 15:47, Stafford Horne a écrit :

On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour wrote: > Hi Waldemar, > > I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2. Hi Romain, Thank you for reporting and doing the initial investigation. Sorry, I haven't built uclibc-ng for a while.

You're welcome, your help is very appreciated.

Have you been able to make much progress?

Yes and no...

I don't get it, there is only SYSCALL_ERROR_NAME from or1k_clone.S. Maybe post the patch diff here.

Sorry I meant SYSCALL_ERROR_NAME which defined __syscall_error. It actually defines it incorrectly as it looks for a definition of PIC, but in uclibc-ng __PIC__ is defined.

...

Maybe something doesn't work with the way we define SYSCALL_ERROR_NAME https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/o…

This fix should not be too hard. SYSCALL_ERROR_NAME is only being used on or1k_clone.S. Let's try to see what is the right thing to replace it with for uclibc-ng.

I haven't looked in depth in the code, I'm not sure how to fix this :-/

No problems, I just posted a patch which I think fixes this can you give it a try? https://mailman.uclibc-ng.org/pipermail/devel/2019-August/001892.html -Stafford

1708

days inactive

1718

days old

devel@uclibc-ng.org

Manage subscription

7 comments

3 participants

tags (0)

participants (3)

Romain Naour
Stafford Horne
Yann Sionneau