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

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

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

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.

...

There is a glibc port I am working on getting working right now:

https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/unix/sy...

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

...

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

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=295307700b49bada3f6e638716f00...

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

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

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

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@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel