Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.

2005-12-12 Thread Clint Adams
 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.

2005-12-11 Thread Clint Adams
 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.

2005-12-11 Thread Daniel Jacobowitz
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.

2005-12-11 Thread David S. Miller
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]