Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Hi Carlos,


>The wrong files are being included. What is your configure line?
As I just change gcc compiler, I don't change glibc configure options which
are:

"unset LD_LIBRARY_PATH; unset LD_RUN_PATH; \
export CC=/Develop/parisc-linux/xc/bin
hppa-linux-gcc; \
export CLFAGS="-O2 -g";  export PATH="/Develop/parisc-linux/xc/bin:$PATH";
\
/Develop/parisc-linux/src/glibc/configure --target=hppa-linux --host=hppa-linux
\
--build=hppa-linux --prefix=/opt/palinux-3.5.0/hppa-linux --without-cv \
--disable-profile --enable-hacker-mode --enable-add-ons=linuxthreads \
--with-headers=/Develop/parisc-linux/src/linux/include
"

hmm I have a look by getting an objdump of elf/dl-symaddr.o (as hppa/dl-symaddr.c
include hppa/dl-machine.h) but I don't find any set_dp? (still have to have
a look with gcc-3.3 for comparison)

Cheers,
    Joel





-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

>-- Original Message --
>Date: Wed, 11 Feb 2004 10:22:24 +0100
>From: "Joel Soete" <soete.joel@tiscali.be>
>Subject: Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb
>To: "Carlos O'Donell" <carlos@baldric.uwo.ca>
>Cc: "James Morrison" <ja2morri@csclub.uwaterloo.ca>,
> parisc-linux@lists.parisc-linux.org,
> "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>
>
>Hi Carlos,
>
>
>The wrong files are being included. What is your configure line?
>As I just change gcc compiler, I don't change glibc configure options which
are:

"unset LD_LIBRARY_PATH; unset LD_RUN_PATH; \
export CC=/Develop/parisc-linux/xc/bin/hppa-linux-gcc; \
export CLFAGS="-O2 -g"; export PATH="/Develop/parisc-linux/xc/bin:$PATH";
\
/Develop/parisc-linux/src/glibc/configure --target=hppa-linux \
--host=hppa-linux --build=hppa-linux \
--prefix=/opt/palinux-3.5.0/hppa-linux --without-cvs \
--disable-profile --enable-hacker-mode --enable-add-ons=linuxthreads \
--with-headers=/Develop/parisc-linux/src/linux/include
"
>
[snip] (still have to have a look with gcc-3.3 for comparison)
>
with same glibc cvs src + your patch and gcc-3.3, no pb
but always same pb with gcc-snapshot (aka 3.5).

I find an interesting differnce between glibc config.h:
--- gcc-3.5.0//glibc/config.h	2004-02-11 15:07:53.667245536 +0100
+++ gcc-3.3.3//glibc/config.h	2004-02-11 15:26:00.256058928 +0100
@@ -104,7 +104,7 @@
 
 /* Define if __asm () on built-in function's prototype causes redirection
of
    the builtin.  */
-#define	HAVE_BUILTIN_REDIRECTION 1
+/* #undef	HAVE_BUILTIN_REDIRECTION */
 
 /* Define if the __thread keyword is supported.  */
 /* #undef HAVE___THREAD */

Where should look for to attempt to fix my pb?

Thanks in advance,

    Joel


-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Carlos O'Donell]

> with same glibc cvs src + your patch and gcc-3.3, no pb
> but always same pb with gcc-snapshot (aka 3.5).
> 
> I find an interesting differnce between glibc config.h:
> --- gcc-3.5.0//glibc/config.h	2004-02-11 15:07:53.667245536 +0100
> +++ gcc-3.3.3//glibc/config.h	2004-02-11 15:26:00.256058928 +0100
> @@ -104,7 +104,7 @@
>  
>  /* Define if __asm () on built-in function's prototype causes redirection
> of
>     the builtin.  */
> -#define	HAVE_BUILTIN_REDIRECTION 1
> +/* #undef	HAVE_BUILTIN_REDIRECTION */
>  
>  /* Define if the __thread keyword is supported.  */
>  /* #undef HAVE___THREAD */
> 
> Where should look for to attempt to fix my pb?

Unknown. gcc-3.5 requires some non-trivial changes to code. You really
have to work with the gcc developers here. I tried building kernels with
3.5 but it's too much work right now, I'm sticking with the gcc-3.3
release until 3.5 matures and all the problems are understood. Stop
using gcc-snapshot to compile glibc :)

c.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

[snip]
> Stop using gcc-snapshot to compile glibc :)

Ok I will do the same.

Thanks for your attention,
    Joel

-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Hi Carlos,

I find a better reason why the build of glibc failed with gcc-3.5: here is
the dump of rtld.os (which would contains ref to set_dp):
with gcc-3.3
------------
palx2000:/Develop/parisc-linux/build/glibc# objdump -d ./elf/rtld.os | more

./elf/rtld.os:     file format elf32-hppa-linux

Disassembly of section .text:

00000000 <set_dp>:
       0:	4b 54 00 48 	ldw 24(,r26),r20
       4:	0e 88 10 9b 	ldw 4(,r20),dp
       8:	e8 40 c0 00 	bv r0(rp)
       c:	08 1a 02 5c 	copy r26,ret0

00000010 <_start>:
      10:	37 de 00 80 	ldo 40(sp),sp
      14:	6b d9 3f b1 	stw r25,-28(,sp)
      18:	6b d8 3f a9 	stw r24,-2c(,sp)
      1c:	ea 60 00 00 	b,l 24 <_start+0x14>,r19
      20:	d6 60 1c 1e 	depwi 0,31,2,r19
      24:	2a 60 00 00 	addil 0,r19,%r1
      28:	34 3a 00 00 	ldo 0(r1),r26
      2c:	2a 60 00 00 	addil 0,r19,%r1
      30:	48 34 00 00 	ldw 0(,r1),r20
      34:	0a 9a 04 14 	sub r26,r20,r20
      38:	0f 50 10 b3 	ldw,ma 8(,r26),r19
      3c:	86 66 20 12 	cmpib,=,n 3,r19,4c <_start+0x3c>
      40:	8e 60 3f ef 	cmpib,<>,n 0,r19,3c <_start+0x2c>
      44:	0f 50 10 b3 	ldw,ma 8(,r26),r19
      48:	04 00 00 00 	iitlbp r0,(sr0,r0)
      4c:	0f 59 10 93 	ldw -4(,r26),r19
      50:	0a 93 06 13 	add r19,r20,r19
      54:	e8 40 07 f0 	b,l 454 <_dl_start>,rp
      58:	37 1a 3f f9 	ldo -4(r24),r26

========><========

with gcc-3.5
------------
palx4000:/Develop/parisc-linux/build/glibc# objdump -d ./elf/rtld.os | more

./elf/rtld.os:     file format elf32-hppa-linux

Disassembly of section .text:

00000000 <_start>:
       0:	37 de 00 80 	ldo 40(sp),sp
       4:	6b d9 3f b1 	stw r25,-28(sp)
       8:	6b d8 3f a9 	stw r24,-2c(sp)
       c:	ea 60 00 00 	b,l 14 <_start+0x14>,r19
      10:	d6 60 1c 1e 	depwi 0,31,2,r19
      14:	2a 60 00 00 	addil 0,r19,%r1
      18:	34 3a 00 00 	ldo 0(r1),r26
      1c:	2a 60 00 00 	addil 0,r19,%r1
      20:	48 34 00 00 	ldw 0(r1),r20
      24:	0a 9a 04 14 	sub r26,r20,r20
      28:	0f 50 10 b3 	ldw,ma 8(,r26),r19
      2c:	86 66 20 12 	cmpib,=,n 3,r19,3c <_start+0x3c>
      30:	8e 60 3f ef 	cmpib,<>,n 0,r19,2c <_start+0x2c>
      34:	0f 50 10 b3 	ldw,ma 8(,r26),r19
      38:	04 00 00 00 	iitlbp r0,(sr0,r0)
      3c:	0f 59 10 93 	ldw -4(,r26),r19
      40:	0a 93 06 13 	add r19,r20,r19
      44:	e8 41 02 84 	b,l 318c <_dl_start>,rp
      48:	37 1a 3f f9 	ldo -4(r24),r26

Why ref to <set_dp> is removed by gcc-3.5?
Is there a new optimization in gcc which remove "defined but not used" in
resulting obj?

Should I log a pb near gcc team?

Thanks again,
    Joel


-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Carlos O'Donell]

> 00000000 <set_dp>:
>        0:	4b 54 00 48 	ldw 24(,r26),r20
>        4:	0e 88 10 9b 	ldw 4(,r20),dp
>        8:	e8 40 c0 00 	bv r0(rp)
>        c:	08 1a 02 5c 	copy r26,ret0
> 
> Should I log a pb near gcc team?

Aggressive inlining, and inlining mistakes might cause the function to 
disapper. Unless you can produce a *small* testcase the gcc team will
not look at the bug. You can't say "glibc doesn't build with gcc-3.5"
... well I guess you can, but nobody will have a clue how to fix the
issue.

Cheers,
Carlos.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Grant Grundler]

On Fri, Feb 13, 2004 at 02:49:08PM -0500, Carlos O'Donell wrote:
> Aggressive inlining, and inlining mistakes might cause the function to 
> disapper. Unless you can produce a *small* testcase the gcc team will
> not look at the bug. You can't say "glibc doesn't build with gcc-3.5"
> ... well I guess you can, but nobody will have a clue how to fix the
> issue.

And he should say *something*.
Pointing at the problem is a first step towards fixing it.
Don't wait until you have a "small" test case to point out a problem
since one might never (have time to) find one.

Even though I fix very few bugs these days, I'm grateful for
every bug report.

grant

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Grant Grundler wrote:
> On Fri, Feb 13, 2004 at 02:49:08PM -0500, Carlos O'Donell wrote:
> 
>>Aggressive inlining, and inlining mistakes might cause the function to 
>>disapper. Unless you can produce a *small* testcase the gcc team will
>>not look at the bug. You can't say "glibc doesn't build with gcc-3.5"
>>... well I guess you can, but nobody will have a clue how to fix the
>>issue.
> 
I understand, so better try to find a fix myself?
In the mean time, as James find the shmem BUG(), I take a more to time to look for gcc ml archive ;)
And I find on gcc-help a another pb of asm inlining <http://gcc.gnu.org/ml/gcc-help/2004-02/msg00076.html>
and advise of change <http://gcc.gnu.org/ml/gcc-help/2004-02/msg00077.html>.
If I don't reach to find an elegant solution, can I also address some messages on gcc-help ml?
> 
> And he should say *something*.
> Pointing at the problem is a first step towards fixing it.
> Don't wait until you have a "small" test case to point out a problem
> since one might never (have time to) find one.
> 
> Even though I fix very few bugs these days, I'm grateful for
> every bug report.
> 
Thanks to all for advise and attention,
	Joel

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Carlos O'Donell]

> > Aggressive inlining, and inlining mistakes might cause the function to 
> > disapper. Unless you can produce a *small* testcase the gcc team will
> > not look at the bug. You can't say "glibc doesn't build with gcc-3.5"
> > ... well I guess you can, but nobody will have a clue how to fix the
> > issue.
> 
> And he should say *something*.
> Pointing at the problem is a first step towards fixing it.
> Don't wait until you have a "small" test case to point out a problem
> since one might never (have time to) find one.
> 
> Even though I fix very few bugs these days, I'm grateful for
> every bug report.

I was too harsh, sorry for that, you should really submit a bug report
saying that glibc 2.3.3 doesn't build with gcc-3.5 on hppa-linux. It's
the truth, and you don't know why. The best you can do is list the 
steps you used to recreate the problem.

Thanks for setting me straight Grant! :)

c.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Carlos O'Donell wrote:
>>>Aggressive inlining, and inlining mistakes might cause the function to 
>>>disapper. Unless you can produce a *small* testcase the gcc team will
>>>not look at the bug. You can't say "glibc doesn't build with gcc-3.5"
>>>... well I guess you can, but nobody will have a clue how to fix the
>>>issue.
>>
>>And he should say *something*.
>>Pointing at the problem is a first step towards fixing it.
>>Don't wait until you have a "small" test case to point out a problem
>>since one might never (have time to) find one.
>>
>>Even though I fix very few bugs these days, I'm grateful for
>>every bug report.
> 
> 
> I was too harsh, sorry for that, you should really submit a bug report
> saying that glibc 2.3.3 doesn't build with gcc-3.5 on hppa-linux. It's
> the truth, and you don't know why. The best you can do is list the 
> steps you used to recreate the problem.
> 
Ok, I will try to report as much detail as I can.

Thanks for all,
	Joel

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

> Ok, I will try to report as much detail as I can.

Hi all,

Just in case of some interest interest, here is the pr ref:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14163>

hth,
    Joel


----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 €/mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Carlos O'Donell]

On Mon, Feb 16, 2004 at 06:31:41PM +0100, Joel Soete wrote:
> > Ok, I will try to report as much detail as I can.
> 
> Hi all,
> 
> Just in case of some interest interest, here is the pr ref:
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14163>
> 
> hth,
>     Joel

Joel,

Excellent! Thanks for posting the PR, the person answering the PR is
correct, we should be indicating to gcc that set_dp is being used by
assembly.

I'm building with a fix right now "__attribute__((used))" to warn
gcc-3.5 that it should not remove the function. I hadn't even realized
that it was only being called by assembly, hence gcc-3.5 is doing a
*better* job of removing apparently dead code.

When the build finishes I'll update my glibc patches online.

c.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 8460 bytes --]

Carlos,

>I'm building with a fix right now "__attribute__((used))" to war
> gcc-3.5 that it should not remove the function. I hadn't even realized
>that it was only being called by assembly, hence gcc-3.5 is doing a
>*better* job of removing apparently dead code.
>
>When the build finishes I'll update my glibc patches online

Ah :)
So you would certainly need some more hack because of lvalue casting.
Here are some one which could already help you:
--- glibc-2.3.3-20040212/iconv/gconv_simple.c	2004-02-07 17:27:50.000000000
+0100
+++ glibc-2.3.3-20040209/iconv/gconv_simple.c	2004-02-09 18:44:41.217390320
+0100
@@ -453,9 +453,11 @@
 #if __BYTE_ORDER == __BIG_ENDIAN
   /* Sigh, we have to do some real work.  */
   size_t cnt;
+  uint32_t *outptr32 = (uint32_t *) outptr;
 
   for (cnt = 0; cnt < n_convert; ++cnt, inptr += 4)
-    *((uint32_t *) outptr)++ = bswap_32 (*(const uint32_t *) inptr);
+    *outptr32++ = bswap_32 (*(const uint32_t *) inptr);
+  outptr = (unsigned char *) outptr32;
 
   *inptrp = inptr;
   *outptrp = outptr;
=========><=========
I already submitted it and accepted by its maintainer (as it is just a complement
to his job) but not yet ci.

=========><=========
--- glibc-2.3.3-20040212/elf/dl-load.c	2004-02-09 08:03:48.000000000 +0100
+++ glibc-2.3.3-20040209/elf/dl-load.c	2004-02-10 16:32:53.250787488 +0100
@@ -1226,9 +1226,13 @@
 			    (header->e_phnum * sizeof (ElfW(Phdr))));
 	l->l_phdr_allocated = 1;
       }
-    else
+    else {
       /* Adjust the PT_PHDR value by the runtime load address.  */
-      (ElfW(Addr)) l->l_phdr += l->l_addr;
+      /*       (ElfW(Addr)) l->l_phdr += l->l_addr; */
+      ElfW(Addr) *tmpp = (ElfW(Addr) *) l->l_phdr;
+      tmpp += l->l_addr;
+      l->l_phdr = (ElfW(Phdr) *) tmpp;
+    }
   }
 
 #ifdef USE_TLS
@@ -1253,8 +1257,12 @@
 	  goto call_lose;
 	}
     }
-  else
-    (ElfW(Addr)) l->l_ld += l->l_addr;
+  else {
+    /* (ElfW(Addr)) l->l_ld += l->l_addr; */
+    ElfW(Addr) *tmpp = (ElfW(Addr) *) l->l_phdr;
+    tmpp += l->l_addr;
+    l->l_phdr = (ElfW(Phdr) *) tmpp;
+  }
 
   l->l_entry += l->l_addr;
 
=========><=========
--- glibc-2.3.3-20040212/sunrpc/rpc/xdr.h	2002-12-16 03:05:49.000000000 +0100
+++ glibc-2.3.3-20040209/sunrpc/rpc/xdr.h	2004-02-10 11:43:02.022656032 +0100
@@ -263,9 +263,19 @@
  * in the RPC code will not work on 64bit Solaris platforms !
  */
 #define IXDR_GET_LONG(buf) \
-	((long)ntohl((u_long)*__extension__((u_int32_t*)(buf))++))
+	({			\
+	long l;			\
+	u_int32_t *buf_u32 = (u_int32_t *) buf;			\
+	l = ((long)ntohl((u_long)*__extension__(buf_u32)++));	\
+	buf = (__typeof__(*buf) *) buf_u32;			\
+	l;							\
+	})
 #define IXDR_PUT_LONG(buf, v) \
-	(*__extension__((u_int32_t*)(buf))++ = (long)htonl((u_long)(v)))
+	do {			\
+	u_int32_t *buf_u32 = (u_int32_t *) buf;			\
+	(*__extension__(buf_u32)++ = (long)htonl((u_long)(v)));	\
+	buf = (__typeof__(*buf) *) buf_u32;			\
+	} while (0)
 #define IXDR_GET_U_LONG(buf)	      ((u_long)IXDR_GET_LONG(buf))
 #define IXDR_PUT_U_LONG(buf, v)	      IXDR_PUT_LONG(buf, (long)(v))
 
=========><=========
But this one is just a very ugly (just quick and dirty :( )

but also:
--- glibc/iconvdata/euc-jisx0213.c.orig	2004-02-18 12:07:32.723703576 +0100
+++ glibc/iconvdata/euc-jisx0213.c	2004-02-18 12:10:13.832211360 +0100
@@ -83,7 +83,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/iso-2022-cn-ext.c.orig	2004-02-18 11:13:48.000000000
+0100
+++ glibc/iconvdata/iso-2022-cn-ext.c	2004-02-18 11:21:56.511671032 +0100
@@ -171,6 +171,7 @@
 #define BODY \
   {									      \
     uint32_t ch = *inptr;						      \
+    uint32_t *outptr32 = (uint32_t *) outptr;				      \
 									      \
     /* This is a 7bit character set, disallow all 8bit characters.  */	
     \
     if (ch > 0x7f)							      \
@@ -377,7 +378,8 @@
 	  }								      \
       }									      \
 									      \
-    *((uint32_t *) outptr)++ = ch;					      \
+    *outptr32++ = ch;							      \
+    outptr = (unsigned char *) outptr32;				      \
   }
 #define EXTRA_LOOP_DECLS	, int *setp
 #define INIT_PARAMS		int set = (*setp >> 3) & CURRENT_MASK; \
--- glibc/iconvdata/shift_jisx0213.c.orig	2004-02-18 12:15:21.953369824 +0100
+++ glibc/iconvdata/shift_jisx0213.c	2004-02-18 12:16:30.127005856 +0100
@@ -83,7 +83,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/tcvn5712-1.c.orig	2004-02-18 11:18:22.027277616 +0100
+++ glibc/iconvdata/tcvn5712-1.c	2004-02-18 11:54:17.527591760 +0100
@@ -68,7 +68,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/tscii.c.orig	2004-02-18 12:23:37.289067352 +0100
+++ glibc/iconvdata/tscii.c	2004-02-18 12:24:25.417750680 +0100
@@ -98,7 +98,9 @@
 		  break;						      \
 		}							      \
 	      /* Write out the pending character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 8;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 8;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      /* Retrieve the successor state.  */			      \
 	      data->__statep->__count =					      \
 		tscii_next_state[(data->__statep->__count >> 4) & 0x0f];      \
=========><=========

But now I need more to try to complete job because:
make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]

Segmentation fault

And dmesg saying:

do_page_fault() pid=6547 command='ld.so.1' type=15 address=0x0016b690
vm_start = 0x00033000, vm_end = 0x00034000

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000111100001111 Not tainted
r00-03  0000000000000000 000000004102b6fc 000000004100721f 00000000faf02040
r04-07  000000004102b6fc 00000000400002b8 00000000faf02158 00000000faf01d8c
r08-11  0000000040170000 0000000000170e60 000000004016fd98 00000000faf01dc0
r12-15  0000000040171e60 0000000000000002 00000000faf02128 ffffffffffffffff
r16-19  00000000faf02180 0000000000000003 0000000000000004 000000004102b6fc
r20-23  000000004102bd80 0000000000000008 000000000016b690 0000000040000000
r24-27  000000000016b690 0000000000001e60 0000000000000003 00000000000c97f0
r28-31  0000000040001000 0000000000000000 00000000faf02180 0000000041013fc7
sr0-3   0000000000003580 0000000000003580 0000000000000000 0000000000003580
sr4-7   0000000000003580 0000000000003580 0000000000003580 0000000000003580

IASQ: 0000000000003580 0000000000003580 IAOQ: 0000000041007293 0000000041007297
 IIR: 0ec01095    ISR: 0000000000003580  IOR: 000000000016b690
 CPU:        8   CR30: 000000003a038000 CR31: 00000000104a4000
 ORIG_R28: 0000000040170000
 IAOQ[0]: 0x41007293
 IAOQ[1]: 0x41007297
 RP(r2): 0x4100721f

But I need first to reboot with a new kernel (the present one was build with
gcc-hppa64-3.3 :( ).
Then get the very last gcc and glibc cvs and restart the scipt :)

hth,
    Joel

PS: I also join diff as files because of bad wraping of my webmail interface.


----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 €/mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr




[-- Attachment #2: GLibC-diff --]
[-- Type: application/octet-stream, Size: 2427 bytes --]

--- glibc-2.3.3-20040212/elf/dl-load.c	2004-02-09 08:03:48.000000000 +0100
+++ glibc-2.3.3-20040209/elf/dl-load.c	2004-02-10 16:32:53.250787488 +0100
@@ -1226,9 +1226,13 @@
 			    (header->e_phnum * sizeof (ElfW(Phdr))));
 	l->l_phdr_allocated = 1;
       }
-    else
+    else {
       /* Adjust the PT_PHDR value by the runtime load address.  */
-      (ElfW(Addr)) l->l_phdr += l->l_addr;
+      /*       (ElfW(Addr)) l->l_phdr += l->l_addr; */
+      ElfW(Addr) *tmpp = (ElfW(Addr) *) l->l_phdr;
+      tmpp += l->l_addr;
+      l->l_phdr = (ElfW(Phdr) *) tmpp;
+    }
   }
 
 #ifdef USE_TLS
@@ -1253,8 +1257,12 @@
 	  goto call_lose;
 	}
     }
-  else
-    (ElfW(Addr)) l->l_ld += l->l_addr;
+  else {
+    /* (ElfW(Addr)) l->l_ld += l->l_addr; */
+    ElfW(Addr) *tmpp = (ElfW(Addr) *) l->l_phdr;
+    tmpp += l->l_addr;
+    l->l_phdr = (ElfW(Phdr) *) tmpp;
+  }
 
   l->l_entry += l->l_addr;
 
--- glibc-2.3.3-20040212/sunrpc/rpc/xdr.h	2002-12-16 03:05:49.000000000 +0100
+++ glibc-2.3.3-20040209/sunrpc/rpc/xdr.h	2004-02-10 11:43:02.022656032 +0100
@@ -263,9 +263,19 @@
  * in the RPC code will not work on 64bit Solaris platforms !
  */
 #define IXDR_GET_LONG(buf) \
-	((long)ntohl((u_long)*__extension__((u_int32_t*)(buf))++))
+	({			\
+	long l;			\
+	u_int32_t *buf_u32 = (u_int32_t *) buf;			\
+	l = ((long)ntohl((u_long)*__extension__(buf_u32)++));	\
+	buf = (__typeof__(*buf) *) buf_u32;			\
+	l;							\
+	})
 #define IXDR_PUT_LONG(buf, v) \
-	(*__extension__((u_int32_t*)(buf))++ = (long)htonl((u_long)(v)))
+	do {			\
+	u_int32_t *buf_u32 = (u_int32_t *) buf;			\
+	(*__extension__(buf_u32)++ = (long)htonl((u_long)(v)));	\
+	buf = (__typeof__(*buf) *) buf_u32;			\
+	} while (0)
 #define IXDR_GET_U_LONG(buf)	      ((u_long)IXDR_GET_LONG(buf))
 #define IXDR_PUT_U_LONG(buf, v)	      IXDR_PUT_LONG(buf, (long)(v))
 
--- glibc-2.3.3-20040212/iconv/gconv_simple.c	2004-02-07 17:27:50.000000000 +0100
+++ glibc-2.3.3-20040209/iconv/gconv_simple.c	2004-02-09 18:44:41.217390320 +0100
@@ -453,9 +453,11 @@
 #if __BYTE_ORDER == __BIG_ENDIAN
   /* Sigh, we have to do some real work.  */
   size_t cnt;
+  uint32_t *outptr32 = (uint32_t *) outptr;
 
   for (cnt = 0; cnt < n_convert; ++cnt, inptr += 4)
-    *((uint32_t *) outptr)++ = bswap_32 (*(const uint32_t *) inptr);
+    *outptr32++ = bswap_32 (*(const uint32_t *) inptr);
+  outptr = (unsigned char *) outptr32;
 
   *inptrp = inptr;
   *outptrp = outptr;

[-- Attachment #3: GLibC-diff2 --]
[-- Type: application/octet-stream, Size: 3382 bytes --]

--- glibc/iconvdata/euc-jisx0213.c.orig	2004-02-18 12:07:32.723703576 +0100
+++ glibc/iconvdata/euc-jisx0213.c	2004-02-18 12:10:13.832211360 +0100
@@ -83,7 +83,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/iso-2022-cn-ext.c.orig	2004-02-18 11:13:48.000000000 +0100
+++ glibc/iconvdata/iso-2022-cn-ext.c	2004-02-18 11:21:56.511671032 +0100
@@ -171,6 +171,7 @@
 #define BODY \
   {									      \
     uint32_t ch = *inptr;						      \
+    uint32_t *outptr32 = (uint32_t *) outptr;				      \
 									      \
     /* This is a 7bit character set, disallow all 8bit characters.  */	      \
     if (ch > 0x7f)							      \
@@ -377,7 +378,8 @@
 	  }								      \
       }									      \
 									      \
-    *((uint32_t *) outptr)++ = ch;					      \
+    *outptr32++ = ch;							      \
+    outptr = (unsigned char *) outptr32;				      \
   }
 #define EXTRA_LOOP_DECLS	, int *setp
 #define INIT_PARAMS		int set = (*setp >> 3) & CURRENT_MASK; \
--- glibc/iconvdata/shift_jisx0213.c.orig	2004-02-18 12:15:21.953369824 +0100
+++ glibc/iconvdata/shift_jisx0213.c	2004-02-18 12:16:30.127005856 +0100
@@ -83,7 +83,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/tcvn5712-1.c.orig	2004-02-18 11:18:22.027277616 +0100
+++ glibc/iconvdata/tcvn5712-1.c	2004-02-18 11:54:17.527591760 +0100
@@ -68,7 +68,9 @@
 	  if (__builtin_expect (outbuf + 4 <= outend, 1))		      \
 	    {								      \
 	      /* Write out the last character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 3;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 3;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      data->__statep->__count = 0;				      \
 	    }								      \
 	  else								      \
--- glibc/iconvdata/tscii.c.orig	2004-02-18 12:23:37.289067352 +0100
+++ glibc/iconvdata/tscii.c	2004-02-18 12:24:25.417750680 +0100
@@ -98,7 +98,9 @@
 		  break;						      \
 		}							      \
 	      /* Write out the pending character.  */			      \
-	      *((uint32_t *) outbuf)++ = data->__statep->__count >> 8;	      \
+	      uint32_t *outptr32 = (uint32_t *) outbuf;			      \
+	      *outptr32++ = data->__statep->__count >> 8;		      \
+	      outbuf = (unsigned char *) outptr32;			      \
 	      /* Retrieve the successor state.  */			      \
 	      data->__statep->__count =					      \
 		tscii_next_state[(data->__statep->__count >> 4) & 0x0f];      \

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Elliott Potter]

On Wed, 18 Feb 2004, Joel Soete wrote:

> Carlos,
> [...]
> But now I need more to try to complete job because:
> make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]
>
> Segmentation fault
>
> And dmesg saying:
>
> do_page_fault() pid=6547 command='ld.so.1' type=15 address=0x0016b690
> vm_start = 0x00033000, vm_end = 0x00034000
>
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001000000111100001111 Not tainted
> r00-03  0000000000000000 000000004102b6fc 000000004100721f 00000000faf02040
> r04-07  000000004102b6fc 00000000400002b8 00000000faf02158 00000000faf01d8c
> r08-11  0000000040170000 0000000000170e60 000000004016fd98 00000000faf01dc0
> r12-15  0000000040171e60 0000000000000002 00000000faf02128 ffffffffffffffff
> r16-19  00000000faf02180 0000000000000003 0000000000000004 000000004102b6fc
> r20-23  000000004102bd80 0000000000000008 000000000016b690 0000000040000000
> r24-27  000000000016b690 0000000000001e60 0000000000000003 00000000000c97f0
> r28-31  0000000040001000 0000000000000000 00000000faf02180 0000000041013fc7
> sr0-3   0000000000003580 0000000000003580 0000000000000000 0000000000003580
> sr4-7   0000000000003580 0000000000003580 0000000000003580 0000000000003580
>
> IASQ: 0000000000003580 0000000000003580 IAOQ: 0000000041007293 0000000041007297
>  IIR: 0ec01095    ISR: 0000000000003580  IOR: 000000000016b690
>  CPU:        8   CR30: 000000003a038000 CR31: 00000000104a4000
>  ORIG_R28: 0000000040170000
>  IAOQ[0]: 0x41007293
>  IAOQ[1]: 0x41007297
>  RP(r2): 0x4100721f

Interesting -- I'm getting a similar crash in a program when it calls
getopt_long() -- this do_page_fault thing.  I'm wondering if the two are
somehow related because it's only this one program that crashes, and
only on the line where getopt_long() is called.  The output in dmesg:

do_page_fault() pid=30051 command='distmk' type=6 address=0x6bc23fdb
vm_start = 0x401ca000, vm_end = 0x401cb000

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 4004ca40 4002c09f bff04040
r04-07  4004d240 000d6f60 bff001b0 bff0018c
r08-11  00000008 00000008 00000001 bff03748
r12-15  000d8470 000ce5c0 00000000 00000000
r16-19  00000000 000b2248 00000004 000007ec
r20-23  4004d238 80000000 6bc23fd9 00000000
r24-27  bff001b0 4004d714 4004cb40 000cfd40
r28-31  000d6762 7efefeff bff040c0 0009cc8b
sr0-3   00001491 00001491 00000000 00001491
sr4-7   00001491 00001491 00001491 00001491

IASQ: 00001491 00001491 IAOQ: 6bc23fdb 6bc23fdf
IIR: 43ffff80    ISR: 00001491  IOR: 401a1a38
CPU:        0   CR30: 4a360000 CR31: 103f0000
 ORIG_R28: 401ca000
 IAOQ[0]: 0x6bc23fdb
 IAOQ[1]: 0x6bc23fdf
 RP(r2): 0x4002c09f


Anyway just a data point.

This is with gcc-3.0.4 and gcc-3.2.3, with kernel 2.4.* and 2.6.2-pa3,
and glibc-2.2.5 (so ... old ...)
--
Elliott

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Hi Elliot,

>Interesting -- I'm getting a similar crash in a program when it calls
>getopt_long() -- this do_page_fault thing.  I'm wondering if the two are
>somehow related because it's only this one program that crashes, and
>only on the line where getopt_long() is called.  The output in dmesg:

For the moment I can just confirm that it's not a kernel pb: I just reboot
a 2.6.3-rc4-pa0 built with gcc-hppa64-3.0.4ds3-8 (a N required a 64bits kernel)
and the same Seg fault occurs.

But in my case, as mentioned sw are still in developement, i suspect more
a mistack in my hack ?)

Cheers,
    Joel

----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 €/mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Carlos O'Donell]

> > But now I need more to try to complete job because:
> > make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]

This is the first time that the loader you built is used. If the loader
is in anyway broke, it will *always* die here first. Just remember this
glibc haiku when you are coding:

	Loader code is bad.
	Dying in sunrpc.
	Blame relocations.

:)

> > do_page_fault() pid=6547 command='ld.so.1' type=15 address=0x0016b690
> > vm_start = 0x00033000, vm_end = 0x00034000
> >
> >      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > PSW: 00000000000001000000111100001111 Not tainted
> > r00-03  0000000000000000 000000004102b6fc 000000004100721f 00000000faf02040
> > r04-07  000000004102b6fc 00000000400002b8 00000000faf02158 00000000faf01d8c
> > r08-11  0000000040170000 0000000000170e60 000000004016fd98 00000000faf01dc0
> > r12-15  0000000040171e60 0000000000000002 00000000faf02128 ffffffffffffffff
> > r16-19  00000000faf02180 0000000000000003 0000000000000004 000000004102b6fc
> > r20-23  000000004102bd80 0000000000000008 000000000016b690 0000000040000000
> > r24-27  000000000016b690 0000000000001e60 0000000000000003 00000000000c97f0
> > r28-31  0000000040001000 0000000000000000 00000000faf02180 0000000041013fc7
> > sr0-3   0000000000003580 0000000000003580 0000000000000000 0000000000003580
> > sr4-7   0000000000003580 0000000000003580 0000000000003580 0000000000003580

Loader died, return address is in the loader or libc. Stack pointer
looks right. PIC register looks correct. If you had a copy of your
/proc/<pid>/maps then you could decipher where 0x4102b6fc pointed.

> > IASQ: 0000000000003580 0000000000003580 IAOQ: 0000000041007293 0000000041007297
> >  IIR: 0ec01095    ISR: 0000000000003580  IOR: 000000000016b690
> >  CPU:        8   CR30: 000000003a038000 CR31: 00000000104a4000
> >  ORIG_R28: 0000000040170000
> >  IAOQ[0]: 0x41007293
> >  IAOQ[1]: 0x41007297
> >  RP(r2): 0x4100721f

Odd, the insns you are executing are really close to your IAOQ
addresses, so the functions are close together.

> Interesting -- I'm getting a similar crash in a program when it calls
> getopt_long() -- this do_page_fault thing.  I'm wondering if the two are
> somehow related because it's only this one program that crashes, and
> only on the line where getopt_long() is called.  The output in dmesg:

No relation. The do_page_fault is an attempt to execute code at an
invalid page. In Joel's case the address is garbage, in your case it's
very very very different.

> do_page_fault() pid=30051 command='distmk' type=6 address=0x6bc23fdb
> vm_start = 0x401ca000, vm_end = 0x401cb000

Your's is a very special failure. The faulting address is actually
an instruction sequence "6bc23fd9 == stw rp,-14(,sp)" Which means that
at some point a *real* address was substituted for a function
descriptor, then dereferenced and jumped into. This *only* used to
happen when running static programs that had static lookup functions. I
can't be certain though without knowing more about your program "distmk."
My guess is that it's a statically compiled binary calling dlopen?

>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111100001111 Not tainted
> r00-03  00000000 4004ca40 4002c09f bff04040
> r04-07  4004d240 000d6f60 bff001b0 bff0018c
> r08-11  00000008 00000008 00000001 bff03748
> r12-15  000d8470 000ce5c0 00000000 00000000
> r16-19  00000000 000b2248 00000004 000007ec
> r20-23  4004d238 80000000 6bc23fd9 00000000
> r24-27  bff001b0 4004d714 4004cb40 000cfd40
> r28-31  000d6762 7efefeff bff040c0 0009cc8b
> sr0-3   00001491 00001491 00000000 00001491
> sr4-7   00001491 00001491 00001491 00001491
> 
> IASQ: 00001491 00001491 IAOQ: 6bc23fdb 6bc23fdf
> IIR: 43ffff80    ISR: 00001491  IOR: 401a1a38
> CPU:        0   CR30: 4a360000 CR31: 103f0000
>  ORIG_R28: 401ca000
>  IAOQ[0]: 0x6bc23fdb
>  IAOQ[1]: 0x6bc23fdf
>  RP(r2): 0x4002c09f
> 
> This is with gcc-3.0.4 and gcc-3.2.3, with kernel 2.4.* and 2.6.2-pa3,
> and glibc-2.2.5 (so ... old ...)

Eeek! Upgrade? I've made so many fixes since then... it's not a very
functioning libc.

c.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Carlos,

>>> > But now I need more to try to complete job because:
>> > make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]
>
>This is the first time that the loader you built is used. If the loader
>is in anyway broke, it will *always* die here first. Just remember this
>glibc haiku when you are coding:
>
>	Loader code is bad.
>	Dying in sunrpc.
>	Blame relocations.
>
>:)

:)) (I was ignoring what an haiku is but now find it as a very good example)


r00-03  0000000000000000 000000004102b6fc 000000004100721f 00000000faf02040

>[snip] If you had a copy of your
/proc/<pid>/maps then you could decipher where 0x4102b6fc pointed.

First just to be sure: don't you speak better of r02=0x4100721f?

unfortunately when I discover dmesg, the process was already died :(
(I will see howto ?)

> > IASQ: 0000000000003580 0000000000003580 IAOQ: 0000000041007293 0000000041007297
> >  IIR: 0ec01095    ISR: 0000000000003580  IO
>: 000000000016b690
> >  CPU:        8   CR30: 000000003a038000 CR31: 00000000104a4000
> >  ORIG_R28: 0000000040170000
> >  IAOQ[0]: 0x41007293
> >  IAOQ[1]: 0x41007297
> >  RP(r2): 0x4100721f

>Odd, the insns you are executing are really close to
>your IAOQ addresses, so the functions are close together.

Thanks for advise, help and attention,
    Joel


----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 €/mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb

[Joel Soete]

Carlos,

>>> > But now I need more to try to complete job because:
>> > make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]
>
Just to be more complet here is the full cmd:
CPP='/Develop/parisc-linux/xc/bin/hppa-linux-gcc -E -x c-header'  /Develop/parisc-linux/build/glibc/elf/ld.so.1
--library-path /Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/glibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/p
arisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads
/Develop/parisc-linux/build/glibc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x
-o /Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.T

which fault immediately as strace confirm:
execve("/Develop/parisc-linux/build/glibc/elf/ld.so.1", ["/Develop/parisc-linux/build/glibc/elf/ld.so.1",
"--library-path", "/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/glibc/nss:/Develop/parisc-linux/build/glibc/nis:/Devel
op/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads",
"/Develop/parisc-linux/build/glibc/sunrpc/rpcgen", "-Y", "../scripts", "-c",
"rpcsvc/bootparam_prot.x", "-o", "/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.T"],
[/* 15 vars */]) = 0
newuname({sys="Linux", node="palx4000", ...}) = 0
brk(0)                                  = 0x4102d000
open("/Develop/parisc-linux/build/glibc/sunrpc/rpcgen", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\2\0\17\0\0\0\1\0\1\16"..., 512)
= 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40000000
mmap(0x10000, 77824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x10000
mmap(0x32000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x12000) = 0x32000
mmap(0x33000, 572, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x33000
close(3)                                = 0
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/Develop/parisc-linux/build/glibc/PARISC32/libc.so.6", O_RDONLY) =
-1 ENOENT (No such file or directory)
stat64("/Develop/parisc-linux/build/glibc/PARISC32", 0xfaf01548) = -1 ENOENT
(No such file or directory)
open("/Develop/parisc-linux/build/glibc/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2\16"..., 512)
= 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 1511008, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40001000
mprotect(0x40154000, 122464, PROT_NONE) = 0
mmap(0x40163000, 53248, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x152000) = 0x40163000
mmap(0x40170000, 7776, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x40170000
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I am very fluent in strace langage ( :) ) but I have the filling that libc.so.6
is wrong? What do you think?

Thanks again,
    Joel.

PS: I will stopped here and tommorrow will try update all stuff and see ;)

----------------------------------------------------------------------------------------
Tiscali ADSL: 19,50 €/mois, pendant 3 mois! L'Internet rapide, c'est pour
tout le monde.
http://reg.tiscali.be/default.asp?lg=fr

[parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb: followup

[Joel Soete]

Carlos,

Carlos O'Donell wrote:
>>>But now I need more to try to complete job because:
>>>make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp]
> 
> 
> This is the first time that the loader you built is used. If the loader
> is in anyway broke, it will *always* die here first. Just remember this
> glibc haiku when you are coding:
> 
> 	Loader code is bad.
> 	Dying in sunrpc.
> 	Blame relocations.
> 
> :)
> 
It takes me some more time because I would test patch by patch with gcc-3.3 if nothing was broken.
But all those patch seems ok with gcc-3.3 (just have to revert it and re-run with make -k check ;) )

That said, I so have on a system (a n4k runing a 64bit 2.6) a ld.so and libc.so build with gcc-3.5 (let me suffix with (3.5) ie: 
ld.so(3.5) and libc.so(3.5)). On another system (a b2k the same 64bit 2.6), I build with gcc-3.3.3 a ld.so(3.3) and libc.so(3.3).

The cmd:
CPP='/Develop/parisc-linux/xc/bin/hppa-linux-gcc -E -x c-header'  /Develop/parisc-linux/build/glibc/elf/ld.so.1
--library-path 
/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/glibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/p
arisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads
/Develop/parisc-linux/build/glibc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x
-o /Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.T

failled with gcc-3.5
otc ok with gcc-3.3

Now if on the N I replace libc.so(3.5) by libc.so(3.3) the cmd (ie using ld.so(3.5)) always failled
OTC if on the B I replace libc.so(3.3) by libc.so(3.5) the cmd (ie using ld.so(3.3)) works fine.
so it confirms that the loader is broken :(

So I have to figure out what goes wrong in "relocation". Can you help me by pointing out some files and may functions to specialy 
analyse :).

Thanks in advance,
	Joel

BTW: The previous mentioned patch are (afaik) of general interest (not hppa specific) but would you like that I submit you first 
so that you could submit it to glibc maintainers or do you prefer that i manage that myself?

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb: followup

[Carlos O'Donell]

On Sat, Feb 21, 2004 at 07:01:39PM +0000, Joel Soete wrote:
> It takes me some more time because I would test patch by patch with gcc-3.3 
> if nothing was broken.
> But all those patch seems ok with gcc-3.3 (just have to revert it and 
> re-run with make -k check ;) )

Yes, it is a lot of work. The fame will all be yours though.
 
> So I have to figure out what goes wrong in "relocation". Can you help me by 
> pointing out some files and may functions to specialy analyse :).

My haiku was really intended to be a joke. Anything could be wrong with
the loader, you have to run it through gdb to get a usefull trace. Even
then you won't have symbols and you'll have to learn to decode the
address from /proc/self/maps and an 'objdump -d xxxxxx.so'. From there
you can find the offending code, go back to the code and examine if it
does anything odd... perhaps isolate what the code does in a testcase
that gcc-3.5 does incorreclty.
 
> BTW: The previous mentioned patch are (afaik) of general interest (not hppa 
> specific) but would you like that I submit you first so that you could 
> submit it to glibc maintainers or do you prefer that i manage that myself?

You should:

a. Make sure that i386 builds with your patches, and passes the
   testsuite without regressions.
b. Cleanup the patches, make *sure* your mailer doesn't wrap them, the
   previous patches were wrapped and broken.
c. Write a 'Changelog' entry for the changes, and describe why you are
   making these changes (e.g. compiling with gcc-3.5). These entries
   have a very special format, look closely, and follow the GNU coding
   convetions.
d. Submit them separately, with a description, changelog, and inline
   patch to the libc-alpha mailing list.

This will be a wonderful learning experience! :)

c.

Re: [parisc-linux] glibc-2.3.3 & gcc-snapshot (3.5.0) pb: followup

[John David Anglin]

> c. Write a 'Changelog' entry for the changes, and describe why you are
>    making these changes (e.g. compiling with gcc-3.5). These entries
>    have a very special format, look closely, and follow the GNU coding
>    convetions.

I'm not sure about glibc but in gcc ChangeLog entries only include
a concise list of changes for each function/macro changed.  The "why"
goes in your patch submission letter.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)