Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
I would have thought that old (r11) would have just been copied to r26. Could you send preprocessed source and compilation details? This is now filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369 I have reassigned the fakeroot bug to gcc-4.0 and marked it up accordingly. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
(I trimmed the cc list a bit) Dave, Could this actually be a gcc problem? Take a look at this: (gdb) bt #0 0x406dbd20 in __canonicalize_funcptr_for_compare () from /usr/lib/debug/libpthread.so.0 #1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8, oact=0xc0241f50) at signals.c:106 #2 0x4035f950 in *__GI___sigaction (sig=value optimized out, act=value optimized out, oact=value optimized out) at ../linuxthreads/sysdeps/pthread/sigaction.c:42 #3 0x4035f748 in __bsd_signal (sig=18, [EMAIL PROTECTED]: 0x42410 __gmon_start__+92828) at signal.c:47 #4 0x0001d690 in main () (gdb) frame 1 #1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8, oact=0xc0241f50) at signals.c:106 106 if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR) (gdb) print old Address requested for identifier old which is in register $r11 (gdb) print /x $r11 $6 = 0x0 (gdb) print /x $pc $7 = 0x406d7424 (gdb) disassemble $pc-16 $pc+4 Dump of assembler code from 0x406d7414 to 0x406d7428: 0x406d7414 __pthread_sigaction+252: stw r20,-138(,sp) 0x406d7418 __pthread_sigaction+256: copy r19,r4 0x406d741c __pthread_sigaction+260: b,l 0x406dbcd8 __canonicalize_funcptr_for_compare,rp 0x406d7420 __pthread_sigaction+264: ldo -2(r11),r26 0x406d7424 __pthread_sigaction+268: copy r4,r19 End of assembler dump. (gdb) Why is it doing that ldo -2(r11),r26 ? I think this version of glibc is built with gcc-4.0 randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that this problem happens to go away when upgrading to 2.6, that's probably acceptable, since 2.4 kernels will have been unsupported on hppa for a full stable release by the time etch comes out. It doesn't go away with 2.6. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
no, it's not fakeroot, it's make segfaulting ... [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16911)] 0x4091fd20 in __canonicalize_funcptr_for_compare () from /lib/libpthread.so.0 (gdb) bt #0 0x4091fd20 in __canonicalize_funcptr_for_compare () from /lib/libpthread.so.0 #1 0x4091b424 in sigaction () from /lib/libpthread.so.0 #2 0x405cc950 in sigaction () from /lib/libc.so.6 #3 0x405cc748 in ssignal () from /lib/libc.so.6 #4 0x0001d690 in main () (gdb) Confirmed. We are passing a function pointer with a value of -2 into __cffc, which should not happen... This code is a bit fragile wrt to glibc's and the toolchain's idea of the GOT layout and function pointer initialization. Carlos and Dave might have a better idea of what is happening :) I've copied Dave and Carlos in case they don't read these lists. Dave and Carlos, this is a problem with the new glibc in Debian unstable. looks like any app that links libpthread will segfault. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
Confirmed. We are passing a function pointer with a value of -2 into __cffc, which should not happen... Is -2 a special signal number? I don't think so. in any case, others have observed that if they use an older glibc, this problem does not happen. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284449: [patch/hppa] fix utimes() for hppa
And while you're at it - what about submitting a kernel patch to add sys_utimes on parisc? willy and i talked about this yesterday. i'll commit this directly to the parisc tree. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284449: [patch/hppa] fix utimes() for hppa
tag 284449 +patch thanks This patch fixes the utimes() problem on hppa -- the cvs patch applied to debian's glibc has a bug in it. tested against 2.3.2.ds1-19 thanks, randolph #! /bin/sh -e # DP: Description: Don't define __ASSUME_UTIMES for hppa # DP: Author: Randolph Chung [EMAIL PROTECTED] # DP: Upstream status: Pending # DP: Date: Thu, 09 Dec 2004 12:01:12 -0800 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 2004-12-09 Randolph Chung [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/kernel-features.h (__ASSUME_UTIMES): Don't define for hppa, which doesn't support this syscall. --- glibc-2.3.2/sysdeps/unix/sysv/linux/kernel-features.h.orig 2004-12-09 11:59:32.138873056 -0800 +++ glibc-2.3.2/sysdeps/unix/sysv/linux/kernel-features.h 2004-12-09 11:59:49.386251056 -0800 @@ -351,7 +351,7 @@ /* The utimes syscall has been available for some architectures forever. For x86 it was introduced after 2.5.75. */ -#if defined __alpha__ || defined __ia64__ || defined __hppa__ \ +#if defined __alpha__ || defined __ia64__ \ || defined __sparc__ \ || (__LINUX_KERNEL_VERSION 132427 defined __i386__) # define __ASSUME_UTIMES 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281993: [patch/hppa] add unwind information to plt fixup routine
Package: glibc Version: 2.3.2-16 Tags: patch Please consider including this patch in the next glibc upload, if it is not picked up from cvs. Not urgent, but will help with gdb users. thanks randolph #! /bin/sh -e # All lines beginning with `# DP:' are a description of the patch. # DP: Description: Add unwind information for the plt fixup routine # DP: Author: Randolph Chung ([EMAIL PROTECTED]) # DP: Upstream status: Submitted and accepted on 2004-11-20 # DP: Status Details: Tested with no regressions. # DP: Date: 2004-11-19 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 2004-11-17 Randolph Chung [EMAIL PROTECTED] * sysdeps/hppa/dl-machine.h (TRAMPOLINE_TEMPLATE): Add unwind annotations. --- glibc-2.3.2/sysdeps/hppa/dl-machine.h.orig 2004-11-17 16:57:24.959474368 -0800 +++ glibc-2.3.2/sysdeps/hppa/dl-machine.h 2004-11-17 17:00:22.498484336 -0800 @@ -421,6 +421,9 @@ asm (.globl #tramp_name \n \ .type #tramp_name ,@function\n \ #tramp_name :\n\ + .proc\n\ + .callinfo frame=64,calls,save_rp\n \ + .entry\n \ /* Save return pointer */ \ stw %r2,-20(%sp)\n \ /* Save argument registers in the call stack frame. */ \ @@ -451,7 +454,8 @@ bv %r0(%r22)\n\ /* Return pointer. */ \ ldw -20(%sp),%r2\n \ -); + .exit\n\ + .procend\n); #ifndef PROF #define ELF_MACHINE_RUNTIME_TRAMPOLINE \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218660: [hppa][patch] fix syscalls for hppa
Package: glibc Version: 2.3.2.ds1-8 Severity: important Tags: patch There are some missing paranethses in the hppa syscall code, so some syscalls don't have their arguments loaded correctly (e.g. INLINE_SYSCALL(..., x31, ...) doesn't work for pread). This patch fixes it. thanks randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ #! /bin/sh -e # DP: Description: Make sure syscall arguments are loaded properly # DP: Author: Randolph Chung [EMAIL PROTECTED] # DP: Upstream status: Pending # DP: Date: Sat, 01 Nov 2003 15:36:04 -0800 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 -p0 $0;; -unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p0 $0;; *) echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 esac exit 0 2003-11-01 Randolph Chung [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/hppa/sysdep.h elf/Makefile (LOAD_ARGS): Ensure arguments are loaded correctly --- sysdeps/unix/sysv/linux/hppa/sysdep.h.orig 2003-11-01 14:16:40.0 -0800 +++ sysdeps/unix/sysv/linux/hppa/sysdep.h 2003-11-01 14:17:36.0 -0800 @@ -387,22 +387,22 @@ #define LOAD_ARGS_0() #define LOAD_ARGS_1(r26) \ - register unsigned long __r26 __asm__(r26) = (unsigned long)r26; \ + register unsigned long __r26 __asm__(r26) = (unsigned long)(r26); \ LOAD_ARGS_0() #define LOAD_ARGS_2(r26,r25) \ - register unsigned long __r25 __asm__(r25) = (unsigned long)r25; \ + register unsigned long __r25 __asm__(r25) = (unsigned long)(r25); \ LOAD_ARGS_1(r26) #define LOAD_ARGS_3(r26,r25,r24) \ - register unsigned long __r24 __asm__(r24) = (unsigned long)r24; \ + register unsigned long __r24 __asm__(r24) = (unsigned long)(r24); \ LOAD_ARGS_2(r26,r25) #define LOAD_ARGS_4(r26,r25,r24,r23) \ - register unsigned long __r23 __asm__(r23) = (unsigned long)r23; \ + register unsigned long __r23 __asm__(r23) = (unsigned long)(r23); \ LOAD_ARGS_3(r26,r25,r24) #define LOAD_ARGS_5(r26,r25,r24,r23,r22) \ - register unsigned long __r22 __asm__(r22) = (unsigned long)r22; \ + register unsigned long __r22 __asm__(r22) = (unsigned long)(r22); \ LOAD_ARGS_4(r26,r25,r24,r23) #define LOAD_ARGS_6(r26,r25,r24,r23,r22,r21) \ - register unsigned long __r21 __asm__(r21) = (unsigned long)r21; \ + register unsigned long __r21 __asm__(r21) = (unsigned long)(r21); \ LOAD_ARGS_5(r26,r25,r24,r23,r22) /* Even with zero args we use r20 for the syscall number */
Bug#194435: ppc32: unistd.h _syscall() macros broken with gcc3.3
Software that use the _syscallN macros in asm/unistd.h provided by glibc on PPC32 won't build with gcc3.3 (typically the MacOnLinux runtime environement is affected). asm/unistd.h is not a glibc header and _syscallN() are not supposed to be called by userspace programs. maybe you can use syscall() instead if you really need to? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Bug#194191: [hppa] glibc needs to be rebuilt with fixed gcc-3.2
Filing to make sure we don't release this version of glibc, because it is very broken on hppa. Needs a gcc-3.2 fix as documented in #193207 and then a recompile... It's too bad. Is this bug occured with not only vim but also many applications? yes, anything that uses e.g sigset() will segfault. so far we've seen this with at least vim, tcpdump and a few other executables. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Bug#194191: [hppa] glibc needs to be rebuilt with fixed gcc-3.2
Package: glibc Version: 2.3.1-17 Severity: serious Filing to make sure we don't release this version of glibc, because it is very broken on hppa. Needs a gcc-3.2 fix as documented in #193207 and then a recompile... randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Bug#193656: [hppa] patch to fix funcptr for _start
Package: glibc Version: 2.3.1-17 Severity: important hppa uses function descriptors, so we need a sysdeps/hppa/elf/entry.h (similar to ppc64, ia64, etc). There used to be a kernel workaround for this in 2.4, but we've removed it in 2.5 and this needs to be fixed properly. Will be submitting upstream shortly. dpatch attached. please apply. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ #! /bin/sh -e # All lines beginning with `# DP:' are a description of the patch. # DP: Description: Define entry.h properly for hppa -- we have func descriptors # DP: Author: Randolph Chung [EMAIL PROTECTED] # DP: Upstream status: Pending # DP: Status Details: will be submitted upstream # DP: Date: Thu, 15 May 2003 22:31:50 -0700 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 2003-05-15 Randolph Chung [EMAIL PROTECTED] * sysdep/hppa/elf/entry.h: New file. --- glibc/sysdeps/hppa/elf/entry.h 2003-05-15 22:29:52.0 -0700 +++ glibc/sysdeps/hppa/elf/entry.h 2003-05-15 22:29:52.0 -0700 @@ -0,0 +1,10 @@ +#ifndef __ASSEMBLY__ +extern void _start (void); +#endif + +/* The function's entry point is stored in the first word of the + function descriptor (plabel) of _start(). */ +#define ENTRY_POINT (*(long *)(((long)_start) ~2)) + +/* We have to provide a special declaration. */ +#define ENTRY_POINT_DECL(class) class void _start (void);
Re: 2.3.2-1
A lot of people use ix86. It's majority. It may be radical statement, but I think ix86 user's priority is higher than minor architecture breakage. Many users don't know except for ix86 :-) this is not a democracy :) if we are going to go the route of x86 is 95% of the users, so let's treat x86 special, then we might as well drop support for all the other architectures. BTW, what is the status for hppa? If it's not so much, I would like to help you, AFAIC. Carlos will have a better overall view of what's needed for glibc. I've looked at the nptl part of it a bit. There is work needed for binutils, gcc and glibc. I will be discussing this more with Carlos and Dave (our gcc/binutils upstream maintainer) during gcc-summit at the end of this month. There is a preliminary design for NPTL for hppa. The first step to get this to work is for us to agree on a workable design for implementing this. I hope to get that done by the end of the month. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Bug#193207: [hppa] vim segfaults when using latest glibc
Package: glibc Version: 2.3.1-17 Severity: serious After upgrading to 2.3.1-17, vim will segfault on startup. With the same version of vim but libc6_2.3.1-16, everything is fine. randolph
Re: 2.3.2-1
I don't know what a good answer is. How much do we compensate for porters who don't take care of their toolchain? One of the great things about the Debian release policy IMO is that we do a good job at really supporting the dozen or so architectures we claim to support. We do not compromise and say that it's ok to release something that only works on i386, when another architecture is lagging behind. If you upload glibc-2.3.2 to sarge, all that will do is cause a large number of bugs to be filed against various packages because they will not build on mips, hppa, etc... how does that help anyone or anything? For the most part, the porters are working very hard at keeping things in sync (look at the stats on buildd.d.o ). I can't think of a single architecture where the porters are neglecting their port. That said, some architectures do need more help than others because of lack of upstream support, etc if anyone would like to help do the NPTL work for hppa, please contact me. There have been various discussions about this between Carlos and myself, but it's not something that will happen in a few weeks' time. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
FWD: IMPORTANT glibc fix
FYI. can we please pick this up from cvs for the next glibc upload? thx randolph - Forwarded message from David Mosberger [EMAIL PROTECTED] - Date: Thu, 27 Mar 2003 17:04:33 -0800 From: David Mosberger [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: IMPORTANT glibc fix Reply-To: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] archive/latest/891 The patch below was just applied to the CVS glibc. Since it fixes an important bug, I'd highly recommend for distributors to also apply the patch to their currently shipping version of glibc. --david From: David Mosberger [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ia64: unat restoration fixes for setjmp() getcontext() Date: Thu, 27 Mar 2003 11:40:03 -0800 Reply-To: [EMAIL PROTECTED] The ia64 versions of __sigsetjmp() and getcontext() failed to restore ar.unat before returning. Patch below should fix that. --david 2003-03-27 David Mosberger [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/ia64/getcontext.S: Restore caller's ar.unat before returning. Add missing .mem.offset directives to ensure file gets assembled without warnings. * sysdeps/unix/sysv/linux/ia64/setjmp.S: Ditto. Index: sysdeps/unix/sysv/linux/ia64/setjmp.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/setjmp.S,v retrieving revision 1.7 diff -u -r1.7 setjmp.S --- sysdeps/unix/sysv/linux/ia64/setjmp.S 31 Dec 2002 20:37:30 - 1.7 +++ sysdeps/unix/sysv/linux/ia64/setjmp.S 27 Mar 2003 18:05:14 - @@ -87,21 +87,22 @@ ENTRY(__sigsetjmp) .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(2) alloc loc1=ar.pfs,2,2,2,0 + .save ar.unat, r16 mov r16=ar.unat ;; mov r17=ar.fpsr mov r2=in0 add r3=8,in0 ;; - st8.spill.nta [r2]=sp,16// r12 (sp) - st8.spill.nta [r3]=gp,16// r1 (gp) +.mem.offset 8,0; st8.spill.nta [r2]=sp,16// r12 (sp) +.mem.offset 0,0; st8.spill.nta [r3]=gp,16// r1 (gp) ;; st8.nta [r2]=r16,16 // save caller's unat st8.nta [r3]=r17,16 // save fpsr add r8=0xa0,in0 ;; - st8.spill.nta [r2]=r4,16// r4 - st8.spill.nta [r3]=r5,16// r5 +.mem.offset 8,0; st8.spill.nta [r2]=r4,16// r4 +.mem.offset 0,0; st8.spill.nta [r3]=r5,16// r5 add r9=0xb0,in0 ;; stf.spill.nta [r8]=f2,32 @@ -143,8 +144,8 @@ stf.spill.nta [r8]=f30 stf.spill.nta [r9]=f31 - st8.spill.nta [r2]=r6,16// r6 - st8.spill.nta [r3]=r7,16// r7 +.mem.offset 8,0; st8.spill.nta [r2]=r6,16// r6 +.mem.offset 0,0; st8.spill.nta [r3]=r7,16// r7 ;; mov r23=ar.bsp mov r25=ar.unat @@ -170,9 +171,10 @@ st8.nta [r3]=in0// __jmp_buf br.call.dpnt.few rp=__sigjmp_save .ret0: // force a new bundle ::q - mov r8=0 + mov.m ar.unat=r16 // restore caller's unat mov rp=loc0 mov ar.pfs=loc1 + mov r8=0 ret END(__sigsetjmp) Index: sysdeps/unix/sysv/linux/ia64/getcontext.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/getcontext.S,v retrieving revision 1.6 diff -u -r1.6 getcontext.S --- sysdeps/unix/sysv/linux/ia64/getcontext.S 9 Oct 2002 09:57:46 - 1.6 +++ sysdeps/unix/sysv/linux/ia64/getcontext.S 27 Mar 2003 19:33:04 - @@ -34,6 +34,7 @@ other than the PRESERVED state. */ ENTRY(__getcontext) + .prologue alloc r16 = ar.pfs, 1, 0, 3, 0 // sigprocmask (SIG_BLOCK, NULL, sc-sc_mask): @@ -53,7 +54,9 @@ add r2 = SC_GR+1*8, r32 ;; mov.m rBSP = ar.bsp + .save ar.unat, rUNAT mov.m rUNAT = ar.unat + .body add r3 = SC_GR+4*8, r32 ;; @@ -65,8 +68,8 @@ .mem.offset 8,0; st8.spill [r3] = r6, 48 and rTMP = ~0x3, rRSC ;; - st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) - st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) +.mem.offset 0,0; st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) +.mem.offset 8,0; st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) ;; mov.m ar.rsc = rTMP // put RSE into enforced lazy mode mov.m rNAT = ar.unat @@ -119,8 +122,8 @@ stf.spill [r3] = f31, 32 mov rB1 = b1 ;; + mov ar.unat = rUNAT // we're done spilling integer regs; restore caller's UNaT add r2 = SC_NAT, r32 - nop 0 add r3 = SC_BSP, r32 ;; st8 [r2] = rNAT, (SC_RNAT-SC_NAT) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe.
FWD: IMPORTANT glibc fix
FYI. can we please pick this up from cvs for the next glibc upload? thx randolph - Forwarded message from David Mosberger [EMAIL PROTECTED] - Date: Thu, 27 Mar 2003 17:04:33 -0800 From: David Mosberger [EMAIL PROTECTED] To: [EMAIL PROTECTED], debian-ia64@lists.debian.org Subject: IMPORTANT glibc fix Reply-To: [EMAIL PROTECTED] X-Mailing-List: debian-ia64@lists.debian.org archive/latest/891 The patch below was just applied to the CVS glibc. Since it fixes an important bug, I'd highly recommend for distributors to also apply the patch to their currently shipping version of glibc. --david From: David Mosberger [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ia64: unat restoration fixes for setjmp() getcontext() Date: Thu, 27 Mar 2003 11:40:03 -0800 Reply-To: [EMAIL PROTECTED] The ia64 versions of __sigsetjmp() and getcontext() failed to restore ar.unat before returning. Patch below should fix that. --david 2003-03-27 David Mosberger [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/ia64/getcontext.S: Restore caller's ar.unat before returning. Add missing .mem.offset directives to ensure file gets assembled without warnings. * sysdeps/unix/sysv/linux/ia64/setjmp.S: Ditto. Index: sysdeps/unix/sysv/linux/ia64/setjmp.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/setjmp.S,v retrieving revision 1.7 diff -u -r1.7 setjmp.S --- sysdeps/unix/sysv/linux/ia64/setjmp.S 31 Dec 2002 20:37:30 - 1.7 +++ sysdeps/unix/sysv/linux/ia64/setjmp.S 27 Mar 2003 18:05:14 - @@ -87,21 +87,22 @@ ENTRY(__sigsetjmp) .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(2) alloc loc1=ar.pfs,2,2,2,0 + .save ar.unat, r16 mov r16=ar.unat ;; mov r17=ar.fpsr mov r2=in0 add r3=8,in0 ;; - st8.spill.nta [r2]=sp,16// r12 (sp) - st8.spill.nta [r3]=gp,16// r1 (gp) +.mem.offset 8,0; st8.spill.nta [r2]=sp,16// r12 (sp) +.mem.offset 0,0; st8.spill.nta [r3]=gp,16// r1 (gp) ;; st8.nta [r2]=r16,16 // save caller's unat st8.nta [r3]=r17,16 // save fpsr add r8=0xa0,in0 ;; - st8.spill.nta [r2]=r4,16// r4 - st8.spill.nta [r3]=r5,16// r5 +.mem.offset 8,0; st8.spill.nta [r2]=r4,16// r4 +.mem.offset 0,0; st8.spill.nta [r3]=r5,16// r5 add r9=0xb0,in0 ;; stf.spill.nta [r8]=f2,32 @@ -143,8 +144,8 @@ stf.spill.nta [r8]=f30 stf.spill.nta [r9]=f31 - st8.spill.nta [r2]=r6,16// r6 - st8.spill.nta [r3]=r7,16// r7 +.mem.offset 8,0; st8.spill.nta [r2]=r6,16// r6 +.mem.offset 0,0; st8.spill.nta [r3]=r7,16// r7 ;; mov r23=ar.bsp mov r25=ar.unat @@ -170,9 +171,10 @@ st8.nta [r3]=in0// __jmp_buf br.call.dpnt.few rp=__sigjmp_save .ret0: // force a new bundle ::q - mov r8=0 + mov.m ar.unat=r16 // restore caller's unat mov rp=loc0 mov ar.pfs=loc1 + mov r8=0 ret END(__sigsetjmp) Index: sysdeps/unix/sysv/linux/ia64/getcontext.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/getcontext.S,v retrieving revision 1.6 diff -u -r1.6 getcontext.S --- sysdeps/unix/sysv/linux/ia64/getcontext.S 9 Oct 2002 09:57:46 - 1.6 +++ sysdeps/unix/sysv/linux/ia64/getcontext.S 27 Mar 2003 19:33:04 - @@ -34,6 +34,7 @@ other than the PRESERVED state. */ ENTRY(__getcontext) + .prologue alloc r16 = ar.pfs, 1, 0, 3, 0 // sigprocmask (SIG_BLOCK, NULL, sc-sc_mask): @@ -53,7 +54,9 @@ add r2 = SC_GR+1*8, r32 ;; mov.m rBSP = ar.bsp + .save ar.unat, rUNAT mov.m rUNAT = ar.unat + .body add r3 = SC_GR+4*8, r32 ;; @@ -65,8 +68,8 @@ .mem.offset 8,0; st8.spill [r3] = r6, 48 and rTMP = ~0x3, rRSC ;; - st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) - st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) +.mem.offset 0,0; st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) +.mem.offset 8,0; st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) ;; mov.m ar.rsc = rTMP // put RSE into enforced lazy mode mov.m rNAT = ar.unat @@ -119,8 +122,8 @@ stf.spill [r3] = f31, 32 mov rB1 = b1 ;; + mov ar.unat = rUNAT // we're done spilling integer regs; restore caller's UNaT add r2 = SC_NAT, r32 - nop 0 add r3 = SC_BSP, r32 ;; st8 [r2] = rNAT, (SC_RNAT-SC_NAT) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a
Re: Update to 2.3.2-1
The main part of this patch is already in 2.3.2. However, Randolph Chung's test code has not been applied. Randolph, Could I remove this dpatch? sure. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update to 2.3.2-1
The main part of this patch is already in 2.3.2. However, Randolph Chung's test code has not been applied. Randolph, Could I remove this dpatch? sure. randolph
Re: help needed for defining hppa __clz_tab gcc-compat symbol
In reference to a message from Guido Guenther, dated Mar 01: On Sat, Mar 01, 2003 at 12:04:54PM -0800, Randolph Chung wrote: most of these look like false positives. i have about half of those executables installed on my system and they all work fine. Just to be sure: you have the woody versions of the binaries listed and and a glibc from unstable? yup. Ryan is helping me verify the entire list now, but all the ones we've tested so far are ok. (i also notice that your list doesn't include __clz_tab?) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help needed for defining hppa __clz_tab gcc-compat symbol
In reference to a message from Guido Guenther, dated Mar 01: On Sat, Mar 01, 2003 at 12:38:50PM -0800, Randolph Chung wrote: (i also notice that your list doesn't include __clz_tab?) Yes, I already wondered why. Could you send me a readelf -a libgcc_s.so | grep __clz_tab from your current installation please? legolas[13:15] ~% readelf -a /lib/libgcc_s.so.1 |grep clz_tab legolas[13:15] ~% randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help needed for defining hppa __clz_tab gcc-compat symbol
+libc {
+ GLIBC_2.2 {
+# libgcc-compat.
+__clz_tab;
+ }
+}
Does this help?
nope :(
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#159411: Cannot reproduce
In reference to a message from Johan Walles, dated Jan 27: H. S. Teoh wrote: Could this be an architecture-specific problem? I'm on an i386 FYI. Yes, this is IA64 specific. see http://lists.debian.org/debian-glibc/2003/debian-glibc-200301/msg00328.html randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with 2.3.1-8 for hppa
Oops! I'm sorry, I fixed as follows:
+# Note that parisc64 kernel version scheme is `uname -r`-64.
[...]
- if dpkg --compare-versions $kernel_ver lt 2.4.19-pa17
+ if dpkg --compare-versions $kernel_ver lt 2.4.19-64
then
echo WARNING: This version of libc6 requires that you be running
echo atleast a 2.4.19-pa17 kernel (or 2.5.53-pa3 if you use
not really
if someone builds a kernel themselves and not use a debian kernel
package, then the version is still 2.4.xx-payy, so your check will
succeed even though the custom built kernel is 2.4.19-pa1
i guess you can do something like this:
if [ $ver = ${ver/pa/} ]
then
if dpkg --compare-versions $kernel_ver lt 2.4.19-64
then
[...]
else
if dpkg --compare-versions $kernel_ver lt 2.4.19-pa17
then
[...]
it's kinda ugly, but it should work.
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with 2.3.1-8 for hppa
Oops! I'm sorry, I fixed as follows:
+# Note that parisc64 kernel version scheme is `uname -r`-64.
[...]
- if dpkg --compare-versions $kernel_ver lt 2.4.19-pa17
+ if dpkg --compare-versions $kernel_ver lt 2.4.19-64
then
echo WARNING: This version of libc6 requires that you be
running
echo atleast a 2.4.19-pa17 kernel (or 2.5.53-pa3 if you use
not really
if someone builds a kernel themselves and not use a debian kernel
package, then the version is still 2.4.xx-payy, so your check will
succeed even though the custom built kernel is 2.4.19-pa1
i guess you can do something like this:
if [ $ver = ${ver/pa/} ]
then
if dpkg --compare-versions $kernel_ver lt 2.4.19-64
then
[...]
else
if dpkg --compare-versions $kernel_ver lt 2.4.19-pa17
then
[...]
it's kinda ugly, but it should work.
randolph
Re: Problem with 2.3.1-8 for hppa
In reference to a message from GOTO Masanori, dated Jan 06: At Sun, 5 Jan 2003 23:34:01 -0800, Randolph Chung wrote: So fixing either glibc or libc6 preinst is needed. From Randolph's mail, comparing kernel version with 2.4.19-pa17 in libc6 preinst is needed. I've added changes for the current glibc cvs as follows: looks good to me. Thanks. argh, actually this is not good. please revert it. the debian parisc kernel packages have version numbers like 2.4.19-64, so your check will not work :( randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with 2.3.1-8 for hppa
So fixing either glibc or libc6 preinst is needed. From Randolph's mail, comparing kernel version with 2.4.19-pa17 in libc6 preinst is needed. I've added changes for the current glibc cvs as follows: looks good to me. if there's a common place where the kernel version information is documented, we should also mention that for 2.5 kernels, = 2.5.53-pa3 is needed for parisc64 i don't think we need to check this in preinst tho. thanks, randolph
Re: Problem with 2.3.1-8 for hppa
In reference to a message from GOTO Masanori, dated Jan 06: At Sun, 5 Jan 2003 23:34:01 -0800, Randolph Chung wrote: So fixing either glibc or libc6 preinst is needed. From Randolph's mail, comparing kernel version with 2.4.19-pa17 in libc6 preinst is needed. I've added changes for the current glibc cvs as follows: looks good to me. Thanks. argh, actually this is not good. please revert it. the debian parisc kernel packages have version numbers like 2.4.19-64, so your check will not work :( randolph
Bug#172545: transmeta longrun fails with unstable libc6 (pread/pwrite)
Oy. I don't have access to a transmeta CPU to do any testing or troubleshooting on this. Do you have the skills to look into it more? If not, I don't know how quickly this will be gotten to. This was reported before: http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00397.html randolph
[hppa] problem using glibc2.3 with older 64-bit kernels
This is a heads up for people running 64-bit hppa kernels with new glibc (2.3.1). Make sure you have at least 2.4.19-pa17, otherwise fcntl() will break with the new glibc and you won't be able to use e.g. apt. This was needed to fix some problems with lfs on hppa. Unfortunately it cannot be done in a completely backwards compatible manner. 32-bit kernels are not affected. sigh randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: Glibc status update
In reference to a message from Jeff Bailey, dated Dec 05: Here's your status update. Please note the **NEED HELP HERE** sections. please also pick up 171550 randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Glibc status update
In reference to a message from Jeff Bailey, dated Dec 05: Here's your status update. Please note the **NEED HELP HERE** sections. please also pick up 171550 randolph
Bug#171550: [ia64] [patch] strncpy.S segfault patch
Package: glibc
Version: 2.3.1-5
Severity: important
Tags: patch
This is a slightly modified patch (from the one I forwarded upstream)
for strncpy.S on ia64. It differs only in that it applies against our
2.3.1 tarball rather than cvs.
Please add to the list.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
#! /bin/sh -e
# DP: Description: Fix recovery code in ia64 strncpy routine
# DP: Author: Kenneth W Chen [EMAIL PROTECTED]
# DP: Upstream status: Pending
# DP: Status Details: Submitted to libc-alpha on Dec 2
# DP: Date: Mon, 02 Dec 2002 23:13:31 -0800
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
# append the patch here and adjust the -p? flag in the patch calls.
2002-11-19 Kenneth W. Chen [EMAIL PROTECTED]
* sysdeps/ia64/strncpy.S: (strncpy) initialize ar.ec,
ec is not guaranteed to be zero upon function entry;
fix segfault in recovery 4 section when src length
ends exactly at a page boundary, and there are no
mapping after that page.
2002-12-02 Randolph Chung [EMAIL PROTECTED]
* string/bug-strncpy.c: test case for strncpy segfault
* string/Makefile: add bug-strncpy test case
--- glibc/sysdeps/ia64/strncpy.S.orig 2002-09-30 15:02:45.0 -0700
+++ glibc/sysdeps/ia64/strncpy.S2002-12-02 21:55:48.0 -0800
@@ -63,6 +63,7 @@
mov saved_pr = pr // save the predicate registers
.save ar.lc, saved_lc
mov saved_lc = ar.lc// save the loop counter
+ mov ar.ec = 0
.body
cmp.geu p6, p5 = 24, in2
(p6) br.cond.spnt .short_len
@@ -217,11 +218,13 @@
(p5) mov r[0] = r0
br.cond.sptk .back2
.recovery3:
- add tmp = -MEMLAT * 8, src ;;
+ add tmp = -(MEMLAT + 1) * 8, src ;;
ld8 r[MEMLAT] = [tmp]
br.cond.sptk .back3
.recovery4:
- add tmp = -(MEMLAT - 1) * 8, src ;;
- ld8 r[MEMLAT - 1] = [tmp]
+ cmp.eq p8,p9=0,len
+ add tmp = -MEMLAT * 8, src ;;
+(p8) mov r[MEMLAT - 1] = r0
+(p9) ld8 r[MEMLAT - 1] = [tmp]
br.cond.sptk .back4
END(strncpy)
--- glibc/string/Makefile.orig 2002-12-02 22:26:22.0 -0800
+++ glibc/string/Makefile 2002-12-02 22:27:46.0 -0800
@@ -48,7 +48,7 @@
tests := tester inl-tester noinl-tester testcopy test-ffs \
tst-strlen stratcliff tst-svc tst-inlcall\
bug-strncat1 bug-strspn1 bug-strpbrk1 tst-bswap \
- tst-strtok tst-strxfrm bug-strcoll1
+ tst-strtok tst-strxfrm bug-strcoll1 bug-strncpy
distribute := memcopy.h pagecopy.h tst-svc.expect
--- glibc/string/bug-strncpy.c 2002-12-02 22:27:32.0 -0800
+++ glibc/string/bug-strncpy.c 2002-12-02 22:27:32.0 -0800
@@ -0,0 +1,81 @@
+/* Test case from Kenneth W Chen [EMAIL PROTECTED]; adapted
+ * for glibc by Randolph Chung [EMAIL PROTECTED]
+ *
+ * Tests the case where the src length ends at a page boundary
+ * and the next page is not mapped
+ */
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include sys/shm.h
+#include signal.h
+
+#define MCPYSIZE 2048
+#define SHMSIZE (MCPYSIZE * sizeof(long))
+static int shmid = -1;
+static char* shmaddr;
+
+void sighandler(int sig)
+{
+if (shmid != -1)
+{
+shmdt(shmaddr);
+shmctl(shmid, IPC_RMID, NULL);
+}
+
+exit(1);
+}
+
+int main(int argc, char **argv)
+{
+long buffer[MCPYSIZE];
+int i, j, k, x;
+char *src, *dst;
+size_t len;
+
+shmid = shmget(1, SHMSIZE, IPC_CREAT|SHM_R|SHM_W);
+shmaddr = (char*) shmat(shmid, NULL, SHM_RND);
+
+signal(SIGSEGV, sighandler);
+
+for (i=0; iSHMSIZE; i++)
+shmaddr[i] = i;
+
+dst = (char*) buffer;
+
+for (k=1; k1000; k+=1) {
+for (i=0; i8; i++) {
+for (j=0; j8; j++) {
+
+src = (char*) shmaddr + SHMSIZE - k - i;
+dst = (char*) buffer + j;
+len = k;
+
+// printf(dst %p src %p n %4d\n, dst, src, len);
+strncpy(dst, src, len);
+
+for (x=0; xlen; x++) {
+if (src[x] == 0) break;
+if ( dst[x] != src[x] ) {
+unsigned long * l_src = (unsigned long*) ((unsigned long)
+src[x] -8);
+unsigned long * l_dst = (unsigned long*) ((unsigned long)
+dst[x] -8);
+
+printf(error\t);
+printf(dst %p src %p n %4zd\n, dst, src, len);
+
+printf(%d: %x %x\n, x, dst[x], src[x
Bug#171550: [ia64] [patch] strncpy.S segfault patch
Package: glibc
Version: 2.3.1-5
Severity: important
Tags: patch
This is a slightly modified patch (from the one I forwarded upstream)
for strncpy.S on ia64. It differs only in that it applies against our
2.3.1 tarball rather than cvs.
Please add to the list.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
#! /bin/sh -e
# DP: Description: Fix recovery code in ia64 strncpy routine
# DP: Author: Kenneth W Chen [EMAIL PROTECTED]
# DP: Upstream status: Pending
# DP: Status Details: Submitted to libc-alpha on Dec 2
# DP: Date: Mon, 02 Dec 2002 23:13:31 -0800
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
# append the patch here and adjust the -p? flag in the patch calls.
2002-11-19 Kenneth W. Chen [EMAIL PROTECTED]
* sysdeps/ia64/strncpy.S: (strncpy) initialize ar.ec,
ec is not guaranteed to be zero upon function entry;
fix segfault in recovery 4 section when src length
ends exactly at a page boundary, and there are no
mapping after that page.
2002-12-02 Randolph Chung [EMAIL PROTECTED]
* string/bug-strncpy.c: test case for strncpy segfault
* string/Makefile: add bug-strncpy test case
--- glibc/sysdeps/ia64/strncpy.S.orig 2002-09-30 15:02:45.0 -0700
+++ glibc/sysdeps/ia64/strncpy.S2002-12-02 21:55:48.0 -0800
@@ -63,6 +63,7 @@
mov saved_pr = pr // save the predicate registers
.save ar.lc, saved_lc
mov saved_lc = ar.lc// save the loop counter
+ mov ar.ec = 0
.body
cmp.geu p6, p5 = 24, in2
(p6) br.cond.spnt .short_len
@@ -217,11 +218,13 @@
(p5) mov r[0] = r0
br.cond.sptk .back2
.recovery3:
- add tmp = -MEMLAT * 8, src ;;
+ add tmp = -(MEMLAT + 1) * 8, src ;;
ld8 r[MEMLAT] = [tmp]
br.cond.sptk .back3
.recovery4:
- add tmp = -(MEMLAT - 1) * 8, src ;;
- ld8 r[MEMLAT - 1] = [tmp]
+ cmp.eq p8,p9=0,len
+ add tmp = -MEMLAT * 8, src ;;
+(p8) mov r[MEMLAT - 1] = r0
+(p9) ld8 r[MEMLAT - 1] = [tmp]
br.cond.sptk .back4
END(strncpy)
--- glibc/string/Makefile.orig 2002-12-02 22:26:22.0 -0800
+++ glibc/string/Makefile 2002-12-02 22:27:46.0 -0800
@@ -48,7 +48,7 @@
tests := tester inl-tester noinl-tester testcopy test-ffs \
tst-strlen stratcliff tst-svc tst-inlcall\
bug-strncat1 bug-strspn1 bug-strpbrk1 tst-bswap \
- tst-strtok tst-strxfrm bug-strcoll1
+ tst-strtok tst-strxfrm bug-strcoll1 bug-strncpy
distribute := memcopy.h pagecopy.h tst-svc.expect
--- glibc/string/bug-strncpy.c 2002-12-02 22:27:32.0 -0800
+++ glibc/string/bug-strncpy.c 2002-12-02 22:27:32.0 -0800
@@ -0,0 +1,81 @@
+/* Test case from Kenneth W Chen [EMAIL PROTECTED]; adapted
+ * for glibc by Randolph Chung [EMAIL PROTECTED]
+ *
+ * Tests the case where the src length ends at a page boundary
+ * and the next page is not mapped
+ */
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include sys/shm.h
+#include signal.h
+
+#define MCPYSIZE 2048
+#define SHMSIZE (MCPYSIZE * sizeof(long))
+static int shmid = -1;
+static char* shmaddr;
+
+void sighandler(int sig)
+{
+if (shmid != -1)
+{
+shmdt(shmaddr);
+shmctl(shmid, IPC_RMID, NULL);
+}
+
+exit(1);
+}
+
+int main(int argc, char **argv)
+{
+long buffer[MCPYSIZE];
+int i, j, k, x;
+char *src, *dst;
+size_t len;
+
+shmid = shmget(1, SHMSIZE, IPC_CREAT|SHM_R|SHM_W);
+shmaddr = (char*) shmat(shmid, NULL, SHM_RND);
+
+signal(SIGSEGV, sighandler);
+
+for (i=0; iSHMSIZE; i++)
+shmaddr[i] = i;
+
+dst = (char*) buffer;
+
+for (k=1; k1000; k+=1) {
+for (i=0; i8; i++) {
+for (j=0; j8; j++) {
+
+src = (char*) shmaddr + SHMSIZE - k - i;
+dst = (char*) buffer + j;
+len = k;
+
+// printf(dst %p src %p n %4d\n, dst, src, len);
+strncpy(dst, src, len);
+
+for (x=0; xlen; x++) {
+if (src[x] == 0) break;
+if ( dst[x] != src[x] ) {
+unsigned long * l_src = (unsigned long*) ((unsigned
long) src[x] -8);
+unsigned long * l_dst = (unsigned long*) ((unsigned
long) dst[x] -8);
+
+printf(error\t);
+printf(dst %p src %p n %4zd\n, dst, src, len);
+
+printf(%d: %x %x\n, x, dst[x], src[x
Re: bugs triage?
I'm working on it. I'm entering examination period in university and my time is disappearing. I'm fixing a fesetround() that was just seen on HP's test-drive systems (getting more testing is great!). let me know if i can help :-) randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugs triage?
I'm working on it. I'm entering examination period in university and my time is disappearing. I'm fixing a fesetround() that was just seen on HP's test-drive systems (getting more testing is great!). let me know if i can help :-) randolph
bugs triage?
'. * #170507: glibc: header goofup on hppa breaks XFree86 compilation Package: glibc; Severity: serious; Reported by: Branden Robinson [EMAIL PROTECTED]; Tags: help. Carlos is looking at this one I think. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugs triage?
* #167794: Wrong Pre-Depends Package: libc6; Severity: critical; Reported by: Martin Schulze [EMAIL PROTECTED]; 25 days old. Looks like this might be a problem in the buildd setup? There's not enough information in the bug to say, and I'm not sure why this is assigned to glibc. No, it's not buildd setup; it's the result of a glibc bug (#165456). that bug is closed... so is this not a problem anymore? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bugs triage?
* #167794: Wrong Pre-Depends Package: libc6; Severity: critical; Reported by: Martin Schulze [EMAIL PROTECTED]; 25 days old. Looks like this might be a problem in the buildd setup? There's not enough information in the bug to say, and I'm not sure why this is assigned to glibc. No, it's not buildd setup; it's the result of a glibc bug (#165456). that bug is closed... so is this not a problem anymore? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Bug#171194: [hppa] nscd segfaults on startup
Package: nscd Version: 2.3.1-5 Severity: important # nscd Segmentation fault (core dumped) # gdb /usr/sbin/nscd ./core GNU gdb 5.2.90_2002-11-20-cvs-debian Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux...(no debugging symbols found)... Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/debug/libpthread.so.0...done. Loaded symbols for /usr/lib/debug/libpthread.so.0 Reading symbols from /usr/lib/debug/libnsl.so.1...done. Loaded symbols for /usr/lib/debug/libnsl.so.1 Reading symbols from /usr/lib/debug/libc.so.6...done. Loaded symbols for /usr/lib/debug/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x4000cfe0 in _dl_fini () from /lib/ld.so.1 (gdb) bt #0 0x4000cfe0 in _dl_fini () from /lib/ld.so.1 #1 0x4016e188 in *__GI_exit (status=0) at exit.c:54 #2 0x00011ebc in main () #3 0x401540c8 in __libc_start_main ( main=0x28eb2 argp_program_version_hook+1214, argc=1, ubp_av=0xfaf0040c, init=0x28dba argp_program_version_hook+966, fini=0x28efa argp_program_version_hook+1286, rtld_fini=0, stack_end=0x5) at ../sysdeps/generic/libc-start.c:144 #4 0x00011cdc in _init () Looks like only the parent process dies... after the segfault the children are still running. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#171194: [hppa] nscd segfaults on startup
Package: nscd Version: 2.3.1-5 Severity: important # nscd Segmentation fault (core dumped) # gdb /usr/sbin/nscd ./core GNU gdb 5.2.90_2002-11-20-cvs-debian Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux...(no debugging symbols found)... Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/debug/libpthread.so.0...done. Loaded symbols for /usr/lib/debug/libpthread.so.0 Reading symbols from /usr/lib/debug/libnsl.so.1...done. Loaded symbols for /usr/lib/debug/libnsl.so.1 Reading symbols from /usr/lib/debug/libc.so.6...done. Loaded symbols for /usr/lib/debug/libc.so.6 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 #0 0x4000cfe0 in _dl_fini () from /lib/ld.so.1 (gdb) bt #0 0x4000cfe0 in _dl_fini () from /lib/ld.so.1 #1 0x4016e188 in *__GI_exit (status=0) at exit.c:54 #2 0x00011ebc in main () #3 0x401540c8 in __libc_start_main ( main=0x28eb2 argp_program_version_hook+1214, argc=1, ubp_av=0xfaf0040c, init=0x28dba argp_program_version_hook+966, fini=0x28efa argp_program_version_hook+1286, rtld_fini=0, stack_end=0x5) at ../sysdeps/generic/libc-start.c:144 #4 0x00011cdc in _init () Looks like only the parent process dies... after the segfault the children are still running. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: glibc 2.3.1 - hppa - Test results.
[/libio/tst-mmap-eofsync.out] Error 1 [/libio/tst-mmap-fflushsync.out] Error 1 I would look at these first. Kernel problems. We think we just recently got them fixed. LTP and few broken debian packages alerted us to this problem. Unforunately these are *NOT* fixed, but in any case, it is likely a kernel problem and not a glibc one... [/dlfcn/default.out] Error 1 default fails with the comparison of the dlsym() returned pointer of main against main. hppa, like ia64, has function descriptors the function descriptor returned by _dl_function_address() may be newly allocated. i'm not too surprised this fails. [/dlfcn/tststatic.out] Error 139 I have no idea why these fail :) [/elf/vismain.out] Error 1 `.protected' seems to be handled correctly, good! `protinmod' in main and mod1 don't have same address `protitcpt' in main and mod3 don't have same address seem to be similar to the default case. [/elf/neededtest.out] Error 14 [/elf/neededtest2.out] Error 14 [/elf/neededtest3.out] Error 17 [/elf/neededtest4.out] Error 2 [/elf/circleload1.out] Error 9 Then these (might be some of the same problems as the dlfcn failures). we had the similar failures of these functions with glibc-2.2.5... so at least these are not new. will need to investigate some more to find out what's going on. so, while this is certainly not a *clean* run, it seems to be as good as what we've had :) randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#167608: ldd: ./: No such file or directory
ldd run on any file returns ./: No such file or directory. the bug is somewhat dependent on the version of bash you are using. Apparently 2.05b-3 was ok, but 2.05b-4 broke it.. but I'm not sure what ldd is doing is correct. The offending line is line 113 of ldd: 113 for file do i'm no posix expert, but that looks strange to me. changing that to 'for file in $@; do' ... works, and seems to be more standard.. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#167608: ldd: ./: No such file or directory
ldd run on any file returns ./: No such file or directory. the bug is somewhat dependent on the version of bash you are using. Apparently 2.05b-3 was ok, but 2.05b-4 broke it.. but I'm not sure what ldd is doing is correct. The offending line is line 113 of ldd: 113 for file do i'm no posix expert, but that looks strange to me. changing that to 'for file in $@; do' ... works, and seems to be more standard.. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: ldd problem: has someone broken glibc in unstable?
In reference to a message from Giles Constant, dated Nov 04: And zsh too? [pts/3] | echo $SHELL /usr/bin/zsh [pts/3] | ldd /bin/ls ldd: ./: No such file or directory eh? you realize a script runs using the interpreter encoded in the #! line right? legolas[10:27] ~% head -1 /usr/bin/ldd #! /bin/bash randolph
Bug#166728: Segmentation fault in libc6
I've been using a prgram many years without problem. I have now a segmentation fault. strace shows this : open(/lib/ld-linux.so.2, O_RDONLY)= 3 before the error. How do you expect us to do anything without knowing what program you are running? randolph
Re: pread offset issues with new libc
if (pread(fd, data, 16, CPUID_TMx86_VENDOR_ID) != 16) {
um that last field is an offset, why does it use the vendor ID as
the offset?
randolph
msg01405/pgp0.pgp
Description: PGP signature
Re: pread offset issues with new libc
if (pread(fd, data, 16, CPUID_TMx86_VENDOR_ID) != 16) {
um that last field is an offset, why does it use the vendor ID as
the offset?
randolph
pgpOkAZGqrkzL.pgp
Description: PGP signature
Re: HPPA patches required for 2.3
- math 'tests' = Needs to be updated, poking Randolph. updated and attached. please apply and submit upstream. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ #! /bin/sh -e # DP: Define hppa libm test accepted ulp error tolerances # DP: Author: Randolph Chung [EMAIL PROTECTED] # DP: Upstream Status: Not submitted # DP: Sat, 05 Oct 2002 18:10:32 -0700 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 2002-10-05 Randolph Chung [EMAIL PROTECTED] * sysdeps/hppa/fpu/libm-test-ulps: new file; define hppa expected test tolerances using the procedure documented in math/README.libm-test --- glibc-2.2.94/sysdeps/hppa/fpu/libm-test-ulps~ Sat Mar 9 13:02:37 2002 +++ glibc-2.2.94/sysdeps/hppa/fpu/libm-test-ulpsSat Mar 9 13:02:37 2002 @@ -0,0 +1,890 @@ +# Begin of automatic generation + +# atan2 +Test atan2 (-0.75, -1.0) == -2.49809154479650885165983415456218025: +float: 3 +ifloat: 3 +Test atan2 (0.75, -1.0) == 2.49809154479650885165983415456218025: +float: 3 +ifloat: 3 +Test atan2 (1.390625, 0.9296875) == 0.981498387184244311516296577615519772: +float: 1 +ifloat: 1 + +# atanh +Test atanh (0.75) == 0.972955074527656652552676371721589865: +float: 1 +ifloat: 1 + +# cacosh +Test Real part of: cacosh (-2 - 3 i) == -1.9833870299165354323470769028940395 + +2.141449159960199416055713254211 i: +double: 1 +float: 7 +idouble: 1 +ifloat: 7 +Test Imaginary part of: cacosh (-2 - 3 i) == -1.9833870299165354323470769028940395 + +2.141449159960199416055713254211 i: +double: 1 +float: 3 +idouble: 1 +ifloat: 3 + +# casin +Test Real part of: casin (0.75 + 1.25 i) == 0.453276177638793913448921196101971749 + +1.13239363160530819522266333696834467 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# casinh +Test Real part of: casinh (-2 - 3 i) == -1.9686379257930962917886650952454982 - +0.96465850440760279204541105949953237 i: +double: 5 +float: 1 +idouble: 5 +ifloat: 1 +Test Imaginary part of: casinh (-2 - 3 i) == -1.9686379257930962917886650952454982 - +0.96465850440760279204541105949953237 i: +double: 3 +float: 6 +idouble: 3 +ifloat: 6 +Test Real part of: casinh (0.75 + 1.25 i) == 1.03171853444778027336364058631006594 + +0.911738290968487636358489564316731207 i: +float: 1 +ifloat: 1 +Test Imaginary part of: casinh (0.75 + 1.25 i) == +1.03171853444778027336364058631006594 + 0.911738290968487636358489564316731207 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# catan +Test Real part of: catan (-2 - 3 i) == -1.4099210495965755225306193844604208 - +0.22907268296853876629588180294200276 i: +float: 3 +ifloat: 3 +Test Imaginary part of: catan (-2 - 3 i) == -1.4099210495965755225306193844604208 - +0.22907268296853876629588180294200276 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Real part of: catan (0.75 + 1.25 i) == 1.10714871779409050301706546017853704 + +0.549306144334054845697622618461262852 i: +float: 4 +ifloat: 4 + +# catanh +Test Real part of: catanh (-2 - 3 i) == -0.1469422552975204743278515471595 - +1.3389725222944935611241935759091443 i: +double: 4 +idouble: 4 +Test Imaginary part of: catanh (-2 - 3 i) == -0.1469422552975204743278515471595 +- 1.3389725222944935611241935759091443 i: +float: 4 +ifloat: 4 +Test Real part of: catanh (0.75 + 1.25 i) == 0.261492138795671927078652057366532140 ++ 0.996825126463918666098902241310446708 i: +double: 1 +idouble: 1 +Test Imaginary part of: catanh (0.75 + 1.25 i) == +0.261492138795671927078652057366532140 + 0.996825126463918666098902241310446708 i: +float: 6 +ifloat: 6 + +# cbrt +Test cbrt (-27.0) == -3.0: +double: 1 +idouble: 1 +Test cbrt (0.75) == 0.908560296416069829445605878163630251: +double: 1 +idouble: 1 +Test cbrt (0.9921875) == 0.997389022060725270579075195353955217: +double: 1 +idouble: 1 + +# ccos +Test Imaginary part of: ccos (-2 - 3 i) == -4.1896256909688072301 - +9.1092278937553365979 i: +float: 1 +ifloat: 1 +Test Real part of: ccos (0.75 + 1.25 i) == 1.38173873063425888530729933139078645 - +1.09193013555397466170919531722024128 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Imaginary part of: ccos (0.75 + 1.25 i) == +1.38173873063425888530729933139078645 - 1.09193013555397466170919531722024128 i: +float: 1 +ifloat: 1 + +# ccosh +Test Real part of: ccosh (-2 - 3 i) == -3.7245455049153225654 + +0.5118225699873846088 i: +float: 1 +ifloat: 1 +Test Imaginary part of: ccosh (-2 - 3 i) == -3.7245455049153225654 + +0.5118225699873846088 i: +float: 1 +ifloat: 1 +Test Real part of: ccosh (0.75 + 1.25 i) == 0.408242591877968807788852146397499084 + +0.780365930845853240391326216300863152 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Imaginary
Re: glibc 2.2.94 - HPPA - Satus ok... :}
In reference to a message from Jack Howarth, dated Sep 24: Carlos, So hppa doesn't need any additional libgcc-compat code? Did you try running the perl script I posted to see if there are any libgcc symbols that are being left undefined in binaries? http://sources.redhat.com/ml/libc-alpha/2002-09/msg00164.html Just curious. i've run the script against a fairly large subset of the debian hppa distro. no symbols were reported. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status - compiling on hppa / ld sigsegv's - glibc 2.2.93
there also seems to be a regression in pthreads support for hppa. i'm using Carlos' updated 2.3 pthreads patch. the ex1 test doesn't terminate. This sounds familiar, but i don't remember what the fix was last time it seems that pthread_join() is not working in 2.2.93 for hppa. the threads get started up, and they go through the for loop ok.. but it doesn't exit. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Glibc 2.3 pre-releases
ia64: Randolph Chung i'm not exactly sure what's the deal here yet, but installing freshly built 2.2.93 debs in a new chroot on ia64 gives some scary looking errors: sh-2.05b# dpkg -i libc6.1_2.2.93-1_ia64.deb libc6.1-dev_2.2.93-1_ia64.deb locales_2.2.93-1_all.deb (Reading database ... 9148 files and directories currently installed.) Preparing to replace libc6.1 2.2.5-14.0.1 (using libc6.1_2.2.93-1_ia64.deb) ... Unpacking replacement libc6.1 ... dpkg: error processing libc6.1_2.2.93-1_ia64.deb (--install): package control info rmdir of `CVS' didn't say not a dir: Directory not empty dpkg (subprocess): unable to execute post-installation script: No such file or directory dpkg: error while cleaning up: subprocess post-installation script returned error exit status 2 dpkg (subprocess): failed to exec rm for cleanup: No such file or directory dpkg: error while cleaning up: subprocess rm cleanup returned error exit status 2 dpkg (subprocess): failed to exec dpkg-split to see if it's part of a multiparter: No such file or directory dpkg: error processing libc6.1-dev_2.2.93-1_ia64.deb (--install): subprocess dpkg-split returned error exit status 2 dpkg (subprocess): failed to exec dpkg-split to see if it's part of a multiparter: No such file or directory dpkg: error processing locales_2.2.93-1_all.deb (--install): subprocess dpkg-split returned error exit status 2 Errors were encountered while processing: libc6.1_2.2.93-1_ia64.deb libc6.1-dev_2.2.93-1_ia64.deb locales_2.2.93-1_all.deb Do we need something in the rules file to get rid of CVS directories from the installed build? randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status update hppa - glibc 2.2.92 (Problems with __divdi3)
In reference to a message from Jeff Bailey, dated Sep 02: On Mon, Sep 02, 2002 at 07:38:51PM -0400, Carlos O'Donell wrote: objdump -t /mnt/flaire/src/glibc-upstream-cvs/libc-build/libc.so.6 | grep divdi3 001173d4 l F .text 0028 __udivdi3 *UND* __divdi3_internal It's clearly not there :} there we go... tausq@a500:~/src/glibc-package/hppa-linux/obj$ nm libc.so|grep divdi3 000217f4 t __divdi3 000217f4 t __divdi3_internal 00021924 t __udivdi3 patch attached. together with the two patches carlos posted i was able to build glibc on hppa using the packaging stuff in cvs. randolph #! /bin/sh -e # DP: pull in definition of divdi3_internal for hppa 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.2.92/sysdeps/hppa/Makefile.orig 2002-09-02 21:38:16.0 -0700 +++ glibc-2.2.92/sysdeps/hppa/Makefile 2002-09-02 21:38:41.0 -0700 -26,6 +26,14 CFLAGS-malloc.c += -DMALLOC_ALIGNMENT=16 endif +ifeq ($(subdir),csu) +ifeq (yes,$(build-shared)) +# Compatibility +sysdep_routines += divdi3 +shared-only-routines += divdi3 +endif +endif + ifeq ($(subdir),elf) dl-routines += dl-symaddr dl-fptr rtld-routines += dl-symaddr dl-fptr
Re: Status update hppa - glibc 2.2.92 (Problems with __divdi3)
Excellent! Are you willing to send this patch upstream now? (Do you want me to do it?) It would be nice to show upstream that this port is being hacked on, and it also allows drepper to comment in case it's not exactly right. I'll let Carlos handle feeding this upstream. all those other hppa patches need to get there eventually... randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FWD: Re: [Linux-ia64] latest glibc snapshot does not build on ia64?
drow is right, as usual :-)
randolph
- Forwarded message from Randolph Chung [EMAIL PROTECTED] -
From: Randolph Chung [EMAIL PROTECTED]
To: Wichmann, Mats D [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Reply-To: Randolph Chung [EMAIL PROTECTED]
Subject: Re: [Linux-ia64] latest glibc snapshot does not build on ia64?
Date: Tue, 3 Sep 2002 10:46:43 -0700
In reference to a message from Wichmann, Mats D, dated Sep 03:
Haven't dug into this too much yet; wanted to see if anyone else has
seen this?
Yup.
There's a short glibc patch which takes care of this (should be on the
Debian lists, else I can mail it to you once I get my machine back up).
It's an unofficial patch because it's felt the problem really lies
with binutils and not glibc, so it's not in glibc cvs. The change
is to dl-machine.h if it helps search...
there was a IA64_RELOC_NONE patch, but in a different area of glibc...
looks like we just hit it again at a different spot now...
580 /* ??? Ignore MSB and Instruction format for now. */
581 if (R_IA64_FORMAT (r_type) == R_IA64_FORMAT_64LSB)
582 *reloc_addr = value;
583 else if (R_IA64_FORMAT (r_type) == R_IA64_FORMAT_32LSB)
584 *(int *) reloc_addr = value;
585 else if (r_type == R_IA64_IPLTLSB)
586 {
587 reloc_addr[0] = 0;
588 reloc_addr[1] = 0;
589 }
590 else
591 assert (! unexpected dynamic reloc format);
r_type is 0 at the assertion
randolph
___
Linux-IA64 mailing list
[EMAIL PROTECTED]
http://lists.linuxia64.org/lists/listinfo/linux-ia64
- End forwarded message -
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FWD: Re: [Linux-ia64] latest glibc snapshot does not build on ia64?
i'll try this later
randolph
- Forwarded message from Andreas Schwab [EMAIL PROTECTED] -
To: Randolph Chung [EMAIL PROTECTED]
Cc: Wichmann, Mats D [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [Linux-ia64] latest glibc snapshot does not build on ia64?
From: Andreas Schwab [EMAIL PROTECTED]
Date: Tue, 03 Sep 2002 21:00:41 +0200
Randolph Chung [EMAIL PROTECTED] writes:
| In reference to a message from Wichmann, Mats D, dated Sep 03:
|
| Haven't dug into this too much yet; wanted to see if anyone else has
| seen this?
|
| Yup.
|
| There's a short glibc patch which takes care of this (should be on the
| Debian lists, else I can mail it to you once I get my machine back up).
| It's an unofficial patch because it's felt the problem really lies
| with binutils and not glibc, so it's not in glibc cvs. The change
| is to dl-machine.h if it helps search...
|
| there was a IA64_RELOC_NONE patch, but in a different area of glibc...
| looks like we just hit it again at a different spot now...
It's actually the same spot, but the context has changed a bit. Here is
an updated patch:
Index: dl-machine.h
===
RCS file: /cvs/glibc/libc/sysdeps/ia64/dl-machine.h,v
retrieving revision 1.20
diff -u -p -a -u -p -a -r1.20 dl-machine.h
--- dl-machine.h6 Apr 2002 00:33:23 - 1.20
+++ dl-machine.h3 Sep 2002 18:58:59 -
@@ -546,12 +546,11 @@ elf_machine_rela (struct link_map *map,
# endif
value += map-l_addr;
}
-# ifndef RTLD_BOOTSTRAP
- else if (r_type == R_IA64_NONE)
-return;
-# endif
else
#endif
+ if (r_type == R_IA64_NONE)
+return;
+ else
{
struct link_map *sym_map;
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
- End forwarded message -
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FWD: Re: [Linux-ia64] latest glibc snapshot does not build on ia64?
In reference to a message from Randolph Chung, dated Sep 03:
i'll try this later
well, the lazy answer is that this patch works... replaces the existing
ia64-reloc-none patch
i'll try to spend some more time to track down where the reloc is coming
from so we can try to fix this in binutils, if it's indeed a bug
there...
randolph
#! /bin/sh -e
# DP: Fix R_IA64_NONE relocs.
# DP: From: Andreas Schwab [EMAIL PROTECTED]
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 -p0 $0;;
-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p0 $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0
--- sysdeps/ia64/dl-machine.h~ Sun Mar 24 16:11:20 2002
+++ sysdeps/ia64/dl-machine.h Sun Mar 24 16:14:21 2002
@@ -546,12 +546,11 @@ elf_machine_rela (struct link_map *map,
# endif
value += map-l_addr;
}
-# ifndef RTLD_BOOTSTRAP
- else if (r_type == R_IA64_NONE)
-return;
-# endif
else
#endif
+ if (r_type == R_IA64_NONE)
+return;
+ else
{
struct link_map *sym_map;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
