Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
Unless someone is going to make a concerted and dedicated development effort to do the necessary full analysis and backport all of the necessary changes, I would suggest to simply not enable TLS for the sparc64 glibc build at this time so at least we have something which works. That works. Remove sparc64-tls.dpatch entirely and configure sparc64 with --without-tls. Working debian/sysdeps/sparc.mk attached. GLIBC_PASSES += sparcv9 sparcv9b sparc64 DEB_ARCH_REGULAR_PACKAGES += libc6-sparc64 libc6-sparcv9 libc6-sparcv9b libc6-dev-sparc64 sparc64_MIN_KERNEL_SUPPORTED = 2.4.18 sparc64_configure_target=sparc64-linux sparc64_CC = $(BUILD_CC) -m64 sparc64_extra_cflags = -g1 -O3 sparc64_extra_config_options = $(extra_config_options) --disable-profile --without-tls sparc64_add-ons = linuxthreads $(add-ons) libc6-sparc64_shlib_dep = libc6-sparc64 (= $(shlib_dep_ver)) sparc64_LIBDIR = 64 sparcv9_MIN_KERNEL_SUPPORTED = 2.4.18 sparcv9_configure_target=sparcv9-linux sparcv9_extra_cflags = -g1 -O3 sparcv9_extra_config_options = $(extra_config_options) --disable-profile sparcv9_add-ons = linuxthreads $(add-ons) sparcv9_LIBDIR = /v9 sparcv9b_MIN_KERNEL_SUPPORTED = 2.4.18 sparcv9b_configure_target=sparcv9b-linux sparcv9b_extra_cflags = -g1 -O3 sparcv9b_extra_config_options = $(extra_config_options) --disable-profile sparcv9b_add-ons = linuxthreads $(add-ons) sparcv9b_LIBDIR = /ultra3
Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
There are some critical things missing in the sparc64 TLS support code in the current debian glibc tree, for example none of the TLS relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and therefore so no binary linked against 64-bit libc can execute. Not even /lib64/libc.so.6 --version will work, it will fail because the dynamic linker doesn't understand the TLS relocations present in the /libc64/libc.so.64 binary. Replacing Aurelien's patch with this one fixes the /lib64/libc.so.6: error while loading shared libraries: unexpected reloc type 0x4f problem, and /lib64/libc.so.6 --version works fine. However, 64-bit binaries segfault. #! /bin/sh -e # DP: TLS code for sparc64, taken from CVS if [ $# -ne 2 ]; then echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 fi case $1 in -patch) patch -d $2 -f --no-backup-if-mismatch -p1 $0;; -unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1 $0;; *) echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 esac exit 0 --- glibc-2.3.5.orig/elf/tls-macros.h 2005-11-12 03:47:57.0 +0100 +++ glibc-2.3.5/elf/tls-macros.h2005-11-12 03:56:01.0 +0100 @@ -440,6 +440,74 @@ o5, o7, cc);\ __o0; }) +#elif defined __sparc__ defined __arch64__ + +# define TLS_LE(x) \ + ({ int *__l; \ + asm (sethi %%tle_hix22( #x ), %0 : =r (__l)); \ + asm (xor %1, %%tle_lox10( #x ), %0 : =r (__l) : r (__l)); \ + asm (add %%g7, %1, %0 : =r (__l) : r (__l)); \ + __l; }) + +# ifdef __PIC__ +# define TLS_LOAD_PIC \ + ({ long pc, got; \ + asm (sethi %%hi(_GLOBAL_OFFSET_TABLE_-4), %1\n\t \ + rd %%pc, %0\n\t \ + add %1, %%lo(_GLOBAL_OFFSET_TABLE_+4), %1\n\t \ + add %1, %0, %1\n\t\ + : =r (pc), =r (got)); \ + got; }) +# else +# define TLS_LOAD_PIC \ + ({ long got; \ + asm (.hidden _GLOBAL_OFFSET_TABLE_\n\t \ + sethi %%hi(_GLOBAL_OFFSET_TABLE_), %0\n\t\ + or %0, %%lo(_GLOBAL_OFFSET_TABLE_), %0 \ + : =r (got)); \ + got; }) +# endif + +# define TLS_IE(x) \ + ({ int *__l; \ + asm (sethi %%tie_hi22( #x ), %0 : =r (__l)); \ + asm (add %1, %%tie_lo10( #x ), %0 : =r (__l) : r (__l));\ + asm (ldx [%1 + %2], %0, %%tie_ldx( #x ) \ + : =r (__l) : r (TLS_LOAD_PIC), r (__l)); \ + asm (add %%g7, %1, %0, %%tie_add( #x ) : =r (__l) : r (__l));\ + __l; }) + +# define TLS_LD(x) \ + ({ int *__l; register void *__o0 asm (%o0); \ + long __o; \ + asm (sethi %%tldm_hi22( #x ), %0 : =r (__l)); \ + asm (add %1, %%tldm_lo10( #x ), %0 : =r (__l) : r (__l)); \ + asm (add %1, %2, %0, %%tldm_add( #x ) \ + : =r (__o0) : r (TLS_LOAD_PIC), r (__l)); \ + asm (call __tls_get_addr, %%tgd_call( #x )\n\t \ + nop \ + : =r (__o0) : 0 (__o0) \ + : g1, g2, g3, g4, g5, g6, o1, o2, o3, o4, \ + o5, o7, cc);\ + asm (sethi %%tldo_hix22( #x ), %0 : =r (__o));\ + asm (xor %1, %%tldo_lox10( #x ), %0 : =r (__o) : r (__o)); \ + asm (add %1, %2, %0, %%tldo_add( #x ) : =r (__l) \ + : r (__o0), r (__o)); \ + __l; }) + +# define TLS_GD(x) \ + ({ int *__l; register void *__o0 asm (%o0); \ + asm (sethi %%tgd_hi22( #x ), %0 : =r (__l)); \ + asm (add %1, %%tgd_lo10( #x ), %0 : =r (__l) : r (__l));\ + asm (add %1, %2, %0, %%tgd_add( #x )\ + : =r (__o0) : r (TLS_LOAD_PIC), r (__l)); \ + asm (call __tls_get_addr, %%tgd_call( #x )\n\t \ + nop \ + : =r (__o0)
Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
On Wed, Nov 30, 2005 at 08:14:43PM -0800, David S. Miller wrote: Package: libc6-sparc64 Version: 2.3.5-8 Severity: normal There are some critical things missing in the sparc64 TLS support code in the current debian glibc tree, for example none of the TLS relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and therefore so no binary linked against 64-bit libc can execute. Not even /lib64/libc.so.6 --version will work, it will fail because the dynamic linker doesn't understand the TLS relocations present in the /libc64/libc.so.64 binary. If this sparc TLS support has been backported, this back has missed significant chunks of the necessary changes and now all 64-bit binaries fail to execute on the system. This is a known problem. It was _not_ backported; rather, binutils was updated to one which supported sparc64 TLS, and glibc's configury automatically started enabling it. An upload to fix this has been waiting on a pile of failures to build, also because of the new binutils. Sorry. I would suggest trying to execute a Hello World program, post-build, to avoid major errors like this. There is no way that any of the testsuite executed properly. Perhaps it was built successfully, but none of the programs linking against libc could have executed properly due to this bug. We run the testsuite. Sparc64 is a special case, however, because we can't assume that the buildd can run sparc64 binaries - in practice it can, of course, I'm sure we could do better than we do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
From: Clint Adams [EMAIL PROTECTED] Date: Sun, 11 Dec 2005 17:41:55 -0500 Replacing Aurelien's patch with this one fixes the /lib64/libc.so.6: error while loading shared libraries: unexpected reloc type 0x4f problem, and /lib64/libc.so.6 --version works fine. However, 64-bit binaries segfault. I would suggest not randomly cherry picking patches from the CVS mainline hoping it will make things start to work. There were several other changes necessary to support TLS properly on sparc64 which went into the glibc CVS tree. You'll need more than just the relocation support. Unless someone is going to make a concerted and dedicated development effort to do the necessary full analysis and backport all of the necessary changes, I would suggest to simply not enable TLS for the sparc64 glibc build at this time so at least we have something which works. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
Package: libc6-sparc64 Version: 2.3.5-8 Severity: normal There are some critical things missing in the sparc64 TLS support code in the current debian glibc tree, for example none of the TLS relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and therefore so no binary linked against 64-bit libc can execute. Not even /lib64/libc.so.6 --version will work, it will fail because the dynamic linker doesn't understand the TLS relocations present in the /libc64/libc.so.64 binary. If this sparc TLS support has been backported, this back has missed significant chunks of the necessary changes and now all 64-bit binaries fail to execute on the system. I would suggest trying to execute a Hello World program, post-build, to avoid major errors like this. There is no way that any of the testsuite executed properly. Perhaps it was built successfully, but none of the programs linking against libc could have executed properly due to this bug. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc3-gd2ef5ebb Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6-sparc64 depends on: ii libc6 2.3.5-8GNU C Library: Shared libraries an libc6-sparc64 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]