August 2019 - devel - example.com

[PATCH] or1k: Fix compiling with PIC and latest binutils use PLT for __syscall_error
by Stafford Horne 09 Oct '19

09 Oct '19

This symbol was causing a build failure with the new toolchain. It looks like it has always been wrong. The main issue was checking for PIC rather than __PIC__. Remove all PSEUDO_* macros and ther SYSCALL_ERROR_NAME macro as they are not needed by uclibc-ng, they are used in glibc for building up syscalls there, but not here. Fixes error: /opt/shorne/software/or1k-linux/bin/../lib/gcc/or1k-linux/9.0.1/../../../../or1k-linux/bin/ld: libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol __syscall_error /opt/shorne/software/or1k-linux/bin/../lib/gcc/or1k-linux/9.0.1/../../../../or1k-linux/bin/ld: final link failed: bad value Signed-off-by: Stafford Horne <shorne(a)gmail.com> --- libc/sysdeps/linux/or1k/or1k_clone.S | 8 +++++-- libc/sysdeps/linux/or1k/sysdep.h | 32 ---------------------------- 2 files changed, 6 insertions(+), 34 deletions(-) diff --git a/libc/sysdeps/linux/or1k/or1k_clone.S b/libc/sysdeps/linux/or1k/or1k_clone.S index a2c16ac9e..2de873a02 100644 --- a/libc/sysdeps/linux/or1k/or1k_clone.S +++ b/libc/sysdeps/linux/or1k/or1k_clone.S @@ -71,7 +71,11 @@ L(oldpid): l.ori r3, r11, 0 L(error): - l.j SYSCALL_ERROR_NAME +#ifdef __PIC__ + l.j plt(__syscall_error) +#else + l.j __syscall_error +#endif l.ori r3,r11,0 -PSEUDO_END (__or1k_clone) +END (__or1k_clone) diff --git a/libc/sysdeps/linux/or1k/sysdep.h b/libc/sysdeps/linux/or1k/sysdep.h index 4dba3f2a0..782981c55 100644 --- a/libc/sysdeps/linux/or1k/sysdep.h +++ b/libc/sysdeps/linux/or1k/sysdep.h @@ -43,38 +43,6 @@ License along with the GNU C Library; if not, see l.sys 1; \ l.nop -#define PSEUDO(name, syscall_name, args) \ - ENTRY (name); \ - DO_CALL(syscall_name); \ - /* if -4096 < ret < 0 holds, it's an error */ \ - l.sfgeui r11, 0xf001; \ - l.bf L(pseudo_end); \ - l.nop - -#define PSEUDO_NOERRNO(name, syscall_name, args) \ - ENTRY (name); \ - DO_CALL(syscall_name) - -#define PSEUDO_END(name) \ -L(pseudo_end): \ - l.j SYSCALL_ERROR_NAME; \ - l.ori r3,r11,0; \ - END (name) - -#define PSEUDO_END_NOERRNO(name) \ - END (name) - -#ifndef PIC -/* For static code, on error jump to __syscall_error directly. */ -# define SYSCALL_ERROR_NAME __syscall_error -#elif NOT_IN_libc -/* Use the internal name for libc/libpthread shared objects. */ -# define SYSCALL_ERROR_NAME __GI___syscall_error -#else -/* Otherwise, on error do a full PLT jump. */ -# define SYSCALL_ERROR_NAME plt(__syscall_error) -#endif - /* Make use of .size directive. */ #define ASM_SIZE_DIRECTIVE(name) .size name,.-name; -- 2.21.0

3 3

Potential bug with feof, fgetc, and ferror
by Rosen Penev 29 Aug '19

29 Aug '19

Reference: https://lists.gnu.org/archive/html/bug-ddrescue/2019-05/msg00000.html https://lists.gnu.org/archive/html/bug-ddrescue/2019-05/msg00001.html Basically, these functions are defined as macros and not being included in std. If compiling with GCC libstdcpp, it works because internally, the header #undefs these functions. This is not the case with uClibc++(or maybe some other libc++).

1 0

[ork1] issue with Binutils 2.32 and gcc 9.x
by Romain Naour 26 Aug '19

26 Aug '19

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

3 7