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)

Re: [parisc-linux] Re: [PATCH] gcc/config/pa/ftpr.c fixes for new TRAMPOLINE_TEMPLATE in

[Carlos O'Donell]

> > I'm not quite sure what the "-4" is intended to accomplish, I figure I
> > could have prefixed the TREAMPOLINE_TEMPLATE with another jump that
> > gives the right address? That still makes for an extra jump, and I'd
> > rather have gcc just look in the right place first.
> > 
> > Thoughts on this?
> 
> I'm just back from Japan and still somewhat jet lagged.

No worries!
 
> The change to the TRAMPOLINE_TEMPLATE macro introduces an ABI change.
> In spite of the extra overhead, I think it would be better to do it
> in a way that didn't require a libgcc.a update.  We only do a call
> to fixup when a function pointer hasn't been resolved, so the extra
> overhead in using "-4" isn't huge.

How do we break ABI? How are those templates part of any ABI? If they
weren't written in ASM they'd be changing all the time (except the entry
point symbol).

An alternative is to split into two templates, one for profiling and one
for non-profiling. This would mean that the original _dl_runtime_resolve
function looks the same, while the following template is bigger.

> If we use the "-4" feature, I can reverse the search order in fptr.c
> so that the offset at "-4" is searched first.  This also allows arbitrary
> changes to the code in the rest of the template.

The only reason I wanted to change __cffc was so the bl was found on the
first loop. I later changed the glibc to include the same bl at "-4"
before the function. The "32" must remain for old applications, the "-4"
will work for new applications once that patches go into debian's glibc
(after a round of public testing).

Perhaps I'll let you catch up on all the mail I sent you :)

c.

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

[Joel Soete]

Hi Carlos and Dave,

I am trying my toolchain script against gcc-snapshot and glibc(2.3.3) with
respective Carlos' patches but I met some pb.

The first was against gconv_simple.c for which I find easily the follwing
patch (see <http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/iconv/gconv_simple.c.diff?r1=1.59&r2=1.60&cvsroot=glibc>)
========><========
--- iconv/gconv_simple.c.orig	2004-02-09 15:11:52.000000000 +0100
+++ iconv/gconv_simple.c	2004-02-09 16:07:16.000000000 +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;
========><========

Is it correct?

The next on is more hard to me and find in _buff() from sunrpc/clnt_perr.c:
[snip]
#ifdef _RPC_THREAD_SAFE_
/*
 * Making buf a preprocessor macro requires renaming the local
 * buf variable in a few functions.  Overriding a global variable
 * with a local variable of the same name is a bad idea, anyway.
 */
#define buf ((char *)RPC_THREAD_VARIABLE(clnt_perr_buf_s))
#else
static char *buf;
#endif

static char *
_buf (void)
{
  if (buf == NULL)
    buf = (char *) malloc (256);
  return buf;
}
[snip]

which precompile as follow:
[snip]
static char *auth_errmsg (enum auth_stat stat) ;
# 63 "clnt_perr.c"
static char *
_buf (void)
{
  if (((char *)(__rpc_thread_variables()->clnt_perr_buf_s)) == ((void *)0))
    ((char *)(__rpc_thread_variables()->clnt_perr_buf_s)) = (char *) malloc
(256);
  return ((char *)(__rpc_thread_variables()->clnt_perr_buf_s));
}
[snip]

and failed with error:
clnt_perr.c: In function `_buf':
clnt_perr.c:67: error: invalid lvalue in assignment
make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/clnt_perr.o] Error
1

Any idea?

Thanks in advance,
    Joel

PS: I just attempt this test because I read a lot of akpm patch related to
gcc-35  ;)

-------------------------------------------------------------------------
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

[James Morrison]

"Joel Soete" <soete.joel@tiscali.be> writes:

> Hi Carlos and Dave,
> 
> I am trying my toolchain script against gcc-snapshot and glibc(2.3.3) with
> respective Carlos' patches but I met some pb.
> 
> The first was against gconv_simple.c for which I find easily the follwing
> patch (see <http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/iconv/gconv_simple.c.diff?r1=1.59&r2=1.60&cvsroot=glibc>)
> ========><========
> --- iconv/gconv_simple.c.orig	2004-02-09 15:11:52.000000000 +0100
> +++ iconv/gconv_simple.c	2004-02-09 16:07:16.000000000 +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;
> ========><========
> 
> Is it correct?
> 
> The next on is more hard to me and find in _buff() from sunrpc/clnt_perr.c:
> [snip]
[snip]
> Any idea?

 This patch fixes the problem:
http://sources.redhat.com/ml/libc-hacker/2004-02/msg00005.html
 
> Thanks in advance,
>     Joel
> 
> PS: I just attempt this test because I read a lot of akpm patch related to
> gcc-35  ;)

Jim

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

[Joel Soete]

Hi Jim,

> This patch fixes the problem:http://sources.redhat.com/ml/libc-hacker/20
>4-02/msg00005.html
 
Thanks for help,
    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]

 
After some more hack I reach to this pb:
/Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
collect2: ld returned 1 exit status
make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
1
make[2]: Leaving directory `/Develop/parisc-linux/src/glibc-2.3.3-20040209/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/src/glibc-2.3.3-20040209'
make: *** [all] Error 2

and set_dp only appears in sysdeps/hppa/dl-machine.h

Any idea?

Thanks,
   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]

On Tue, Feb 10, 2004 at 05:46:08PM +0100, Joel Soete wrote:
>  
> After some more hack I reach to this pb:
> /Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
> collect2: ld returned 1 exit status
> make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
> 1
> make[2]: Leaving directory `/Develop/parisc-linux/src/glibc-2.3.3-20040209/iconv'
> make[1]: *** [iconv/others] Error 2
> make[1]: Leaving directory `/Develop/parisc-linux/src/glibc-2.3.3-20040209'
> make: *** [all] Error 2
> 
> and set_dp only appears in sysdeps/hppa/dl-machine.h

The wrong files are being included. What is your configure line?

c.