Seg fault when compiled with -mabi=64 and -lpthread

Seg fault when compiled with -mabi=64 and -lpthread

[Bryan Althouse]

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

I have a problem when linking a 64 bit application with libpthread.  I
appears to link fine, but it will seg fault when I execute it.  I wrote an
empty C program called empty.c:

 

int main (void)

{  

    return 0;

}

 

I cross compile it with:

/opt/redhat/mips64linux-031001/H-i686-pc-linux-gnulibc2.2/bin/mips64-linux-g
nu-gcc -mabi=64 empty.c -o empty -lpthread

The executable will seg fault.  If I remove the -lpthread, it is fine.
Also, if I change the 64 to 32, it is fine.

 

Maybe I have a bad libpthread in /lib64?  If I type "file
/lib64/libpthread-0.10.so" I get: "ELF 64-bit MSB shared object, mips-3 MIPS
R3000_BE, version 1, not stripped".  Looks fine to me.  Should I cross
compile and replace libpthread?  If so, where can I find the source?

 

The other strange thing is that ldd does not work on 64 bit applications.
It will always return:  "not a dynamic executable".  Does anyone know how
this could be fixed?  

 

I'm using a PMC Yosemite board with an RM9224 processor.  The kernel is
2.6.12 64bit SMP.  I am using the PMC supplied cross compile tools, kernel,
and NFS file system. 

 

Thanks for your help!

Bryan

  

 


[-- Attachment #2: Type: text/html, Size: 5425 bytes --]

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Stephen P. Becker]

Bryan Althouse wrote:
> I have a problem when linking a 64 bit application with libpthread.  I
> appears to link fine, but it will seg fault when I execute it.  I wrote
> an empty C program called empty.c:
> 
>  
> 
> int main (void)
> 
> { 
> 
>     return 0;
> 
> }
> 
>  
> 
> I cross compile it with:
> 
> /opt/redhat/mips64linux-031001/H-i686-pc-linux-gnulibc2.2/bin/mips64-linux-gnu-gcc
> –mabi=64 empty.c –o empty –lpthread
> 
> The executable will seg fault.  If I remove the –lpthread, it is fine. 
> Also, if I change the 64 to 32, it is fine.
> 
>  
> 
> Maybe I have a bad libpthread in /lib64?  If I type “file
> /lib64/libpthread-0.10.so” I get: “ELF 64-bit MSB shared object, mips-3
> MIPS R3000_BE, version 1, not stripped”.  Looks fine to me.  Should I
> cross compile and replace libpthread?  If so, where can I find the source?
> 

Wow, so I'm not just smoking crack.  I ran into essentially the same
exact problem with my n32 userland while trying to build glib (not
glibc).  The configure script kept dying while trying to determine if
libpthread was available.  Looking at the config.log, I noticed that the
conftest code was causing a segfault.  Furthermore, this causes a kernel
oops (you should check your kernel logs for an oops).

I isolated the conftest code, and it is available at:
http://beerandrocks.net:8080/~spbecker/oops/

In that directory is also a statically linked big endian n32 executable,
as well as dumps of oops messages that I was able to reproduce 100% of
the time on both ip32 and ip22 systems.  If anyone is in an
experimenting mood, try to run that executable on a mips64 box (with n32
binary support enabled obviously) and see what happens.  The interesting
thing about this problem is that it only happens with recent kernels.  I
can't speak for 2.6.11 since I haven't tested it yet, but the oops only
occurred while running 2.6.12 from cvs HEAD.  When running my 2.6.10
build that has been on my indy for some time, the conftest code runs
fine without any segfault, and there is no kernel oops.

-Steve

RE: Seg fault when compiled with -mabi=64 and -lpthread

[Bryan Althouse]

Steve,

I don't see a kernel oops.  I checked /var/log/messages, and a few others.
I have verified that klogd and syslogd are running.

Bryan

-----Original Message-----
From: Stephen P. Becker [mailto:geoman@gentoo.org] 
Sent: Thursday, June 30, 2005 3:09 PM
To: Bryan Althouse
Cc: 'Linux/MIPS Development'
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread

Bryan Althouse wrote:
> I have a problem when linking a 64 bit application with libpthread.  I
> appears to link fine, but it will seg fault when I execute it.  I wrote
> an empty C program called empty.c:
> 
>  
> 
> int main (void)
> 
> { 
> 
>     return 0;
> 
> }
> 
>  
> 
> I cross compile it with:
> 
>
/opt/redhat/mips64linux-031001/H-i686-pc-linux-gnulibc2.2/bin/mips64-linux-g
nu-gcc
> -mabi=64 empty.c -o empty -lpthread
> 
> The executable will seg fault.  If I remove the -lpthread, it is fine. 
> Also, if I change the 64 to 32, it is fine.
> 
>  
> 
> Maybe I have a bad libpthread in /lib64?  If I type "file
> /lib64/libpthread-0.10.so" I get: "ELF 64-bit MSB shared object, mips-3
> MIPS R3000_BE, version 1, not stripped".  Looks fine to me.  Should I
> cross compile and replace libpthread?  If so, where can I find the source?
> 

Wow, so I'm not just smoking crack.  I ran into essentially the same
exact problem with my n32 userland while trying to build glib (not
glibc).  The configure script kept dying while trying to determine if
libpthread was available.  Looking at the config.log, I noticed that the
conftest code was causing a segfault.  Furthermore, this causes a kernel
oops (you should check your kernel logs for an oops).

I isolated the conftest code, and it is available at:
http://beerandrocks.net:8080/~spbecker/oops/

In that directory is also a statically linked big endian n32 executable,
as well as dumps of oops messages that I was able to reproduce 100% of
the time on both ip32 and ip22 systems.  If anyone is in an
experimenting mood, try to run that executable on a mips64 box (with n32
binary support enabled obviously) and see what happens.  The interesting
thing about this problem is that it only happens with recent kernels.  I
can't speak for 2.6.11 since I haven't tested it yet, but the oops only
occurred while running 2.6.12 from cvs HEAD.  When running my 2.6.10
build that has been on my indy for some time, the conftest code runs
fine without any segfault, and there is no kernel oops.

-Steve

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Ralf Baechle]

On Thu, Jun 30, 2005 at 01:33:39PM -0400, Bryan Althouse wrote:

> The executable will seg fault.  If I remove the -lpthread, it is fine.
> Also, if I change the 64 to 32, it is fine.

I fear you may be hitting these problems simple because you're the first
through the mine field of 64-bit pthreads ;-)  So far most people are
simple running 32-bit software on their 64-bit kernels.  No reason to
panic though, most of the bits are in place, it's just the one or other
insect hiding in the code.

  Ralf

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Daniel Jacobowitz]

On Thu, Jun 30, 2005 at 09:21:11PM +0100, Ralf Baechle wrote:
> On Thu, Jun 30, 2005 at 01:33:39PM -0400, Bryan Althouse wrote:
> 
> > The executable will seg fault.  If I remove the -lpthread, it is fine.
> > Also, if I change the 64 to 32, it is fine.
> 
> I fear you may be hitting these problems simple because you're the first
> through the mine field of 64-bit pthreads ;-)  So far most people are
> simple running 32-bit software on their 64-bit kernels.  No reason to
> panic though, most of the bits are in place, it's just the one or other
> insect hiding in the code.

Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
I don't know how well that works nowadays; but current CVS versions do
work, or did when I last tested (a month or two ago).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Stephen P. Becker]

> Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> I don't know how well that works nowadays; but current CVS versions do
> work, or did when I last tested (a month or two ago).
> 

Hmm, well with respect to my problem, I'm using a pretty recent
toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
Bryan's segfault, but could not.  That code ran without error when I
linked with libpthread.  Any thoughts?

-Steve

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Daniel Jacobowitz]

On Thu, Jun 30, 2005 at 06:09:09PM -0400, Stephen P. Becker wrote:
> 
> > Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> > I don't know how well that works nowadays; but current CVS versions do
> > work, or did when I last tested (a month or two ago).
> > 
> 
> Hmm, well with respect to my problem, I'm using a pretty recent
> toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> Bryan's segfault, but could not.  That code ran without error when I
> linked with libpthread.  Any thoughts?

I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
in a long time.  Try CVS HEAD of glibc instead.

Other than that, you're on your own - building glibc is extremely error
prone.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Kumba]

Daniel Jacobowitz wrote:
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.
> 
> Other than that, you're on your own - building glibc is extremely error
> prone.
> 

I'm thiking this is more a possible oddity/bug in the kernel.  It may be glibc 
related, but I'm no concrete interpreter of strace output.

That said, I tried geoman's conftest.c snippet in an o32/glibc userland, 
n32/glibc userland, and o32/uclibc userland just to see if there was any difference.

The commonalities between all three was something is happening with 
rt_siguspend/sys32_rt_siguspend.  In o32/glibc and o32/uclibc, calls to 
rt_sigsuspend returned EINTR (interrupted system call).  o32 itself generates a 
silent SIGBUS (only seen in strace output.  o32/uclibc seems to complete 
(reaches exit(0)), but its rt_sigsuspend calls were also returning EINTR. 
n32/glibc was the one that generates the Oops message (w/o locking the system up).

The only differences was that o32/glibc and n32/glibc both SIGBUS/SIGSEG, while 
o32/uclibc seems to complete.  This could point to a glibc problem.

Below is the snipped output from strace and ksymoops on n32 (cause strace 
doesn't seem to work in n32 yet):

o32/glibc:
clone(child_stack=0x10003010, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) 
= 9954
write(4, "*\260b \0\0\0\5\0\0\0\0*\257\352H*\253\3H*\253\200\0\4"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [32], 16) = 0
write(4, "*\265\20\200\0\0\0\0\0\0\0\0\0@\10\240\0\0\0\0\200\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [32], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now ~[HUP INT QUIT ILL IOT 
KILL BUS ALRM TERM USR1 CHLD PWR URG IO CONT TTOU PROF XFSZ 32 33 34 35 37 38 39 
40 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 74 77 78 79 80 81 83 84 85 86 87 88 89 90 91 92 94 95 96 99 100 101 105 108 
110 112 114 115 116 117 118 119 120 121 122 123 124 125 126])
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++


n32/glibc:
 >>$31; a80000002001abc4 <do_signal32+1f4/298>

 >>PC;  00000000 Before first symbol

Trace; a80000002001ade8 <_sys32_rt_sigsuspend+180/1a8>
Trace; a80000002001e7f4 <handle_sysn32+54/a0>
Trace; a80000002001e7f4 <handle_sysn32+54/a0>


o32/uclibc:
clone(child_stack=0x100030c0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) 
= 10004
write(4, "\0\0\0\0\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
write(4, "*\263\363\300\0\0\0\0\0\0\0\0\0@\0070\0\0\0\0\200\0\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
write(4, "*\263\363\300\0\0\0\1\0\0\4\2\0@\0070\0\0\0\0\200\0\0\0"..., 148) = 148
write(4, "*\263\363\300\0\0\0\2\0\0\0\0*\2571T*\257iT*\257i\10\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
wait4(10004, NULL, __WCLONE, NULL)      = 10004
exit(0)                                 = ?


Thoughts?


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Maciej W. Rozycki]

On Thu, 30 Jun 2005, Daniel Jacobowitz wrote:

> > Hmm, well with respect to my problem, I'm using a pretty recent
> > toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> > from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> > Bryan's segfault, but could not.  That code ran without error when I
> > linked with libpthread.  Any thoughts?
> 
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.

 Well, I tried a few trivial programs that use libpthread in my (n)64 
environment, which is based on 2.3.5, and they worked just fine.  They 
could have bin as simple as `ls', but as I have seen in the original 
report you do not have to make extensive use of the library to trigger 
problematic behaviour.

 Though it can be related to patches I have applied, me having built glibc 
with GCC 4.0.0 or perhaps it only happens for BE...

> Other than that, you're on your own - building glibc is extremely error
> prone.

 And you may need external patches as glibc is (effectively) not 
maintained.

  Maciej

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Daniel Jacobowitz]

On Fri, Jul 01, 2005 at 09:49:39AM +0100, Maciej W. Rozycki wrote:
>  And you may need external patches as glibc is (effectively) not 
> maintained.

Shall I just stop trying, then?  I'm getting tired of arguing with you
about this.

For the twentieth time: I am doing everything I can to keep glibc HEAD
building for MIPS.  I do not have the time or energy to deal with
Roland's restrictive stable branch rules, so I can not help with 2.3.5.
But if you encounter a problem on HEAD, let me know, and I will either
fix it myself or (if you've got a patch) pester people relentlessly
until it is applied.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Maciej W. Rozycki]

On Fri, 1 Jul 2005, Daniel Jacobowitz wrote:

> >  And you may need external patches as glibc is (effectively) not 
> > maintained.
> 
> Shall I just stop trying, then?  I'm getting tired of arguing with you
> about this.

 Certainly not! -- in this case I haven't meant the MIPS port, but glibc 
as a whole -- just have a look at the response to fixes for the Alpha or 
i386!

 And please forgive me for the feeling of me arguing with you -- it wasn't 
my intention.  Frankly I cannot even realize exactly when it happened.

> For the twentieth time: I am doing everything I can to keep glibc HEAD
> building for MIPS.  I do not have the time or energy to deal with
> Roland's restrictive stable branch rules, so I can not help with 2.3.5.

 Building is not everything. ;-)

> But if you encounter a problem on HEAD, let me know, and I will either
> fix it myself or (if you've got a patch) pester people relentlessly
> until it is applied.

 Certainly -- I'm assuming you are ready for a pile of patches then?  
Well, perhaps not that many, but I think I've got around four that should 
go upstream.  I'll have a look if they apply cleanly.  None of them 
addresses a problem with building though.

  Maciej

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Daniel Jacobowitz]

On Fri, Jul 01, 2005 at 03:10:08PM +0100, Maciej W. Rozycki wrote:
>  Certainly -- I'm assuming you are ready for a pile of patches then?  
> Well, perhaps not that many, but I think I've got around four that should 
> go upstream.  I'll have a look if they apply cleanly.  None of them 
> addresses a problem with building though.

Sure - send them to me, or better yet, put them in bugzilla and make
sure you copy me.  I can't promise you timely response just now because
I'm about twelve feet under on this current project at work, but I'll
do everything I can.

We're going to have automated MIPS regression testing sometime this
year, too.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[sjhill]

> Looks like I should upgrade glibc, and possibly gcc.  When you say that I
> should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
> the linux-mips.org CVS and the closest thing I can find is libc, and it
> looks really old.  I have also found a glibc CVS at
> :pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
> this the "CVS HEAD"?  
> 
> Should I get GCC from the generic GCC site, or should get it from the
> linux-mips CVS?  
> 
> I apologize for the simple questions.  I have not built a tool chain before.
> I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
> these sources for MIPs?
> 
Also, stay away from the HEAD of GCC CVS. GCC-4.1.0 compilers cannot
build Linux kernels.

-Steve

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Stephen P. Becker]

>>Hmm, well with respect to my problem, I'm using a pretty recent
>>toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
>>from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
>>Bryan's segfault, but could not.  That code ran without error when I
>>linked with libpthread.  Any thoughts?
> 
> 
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.
> 
> Other than that, you're on your own - building glibc is extremely error
> prone.
> 

I'm sure it can be error prone, but that isn't the problem here at all.
  My n32 glibc 2.3.5 compiled and seems to work just fine, and I was
able to compile an entire userland around it that has no (other)
problems so far as I can tell.  By this, I mean "emerge system" in
Gentoo terms, which is a pretty good test of whether the toolchain works
or not.  Furthermore, other programs that are linked against libpthread
run without causing a segfault and oops.  I'm talking about glib, as in
the glib that used to be part of GTK+ before it was split out some time
ago.

The segfault with kernel oops that I can't get around occurs while
glib's configure script is checking for libpthread.  Specifically, it
links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
libpthread and then runs it.

I've somewhat convinced myself this is either a kernel and/or a header
problem.  It seems I'm only able to reproduce this problem when trying
to compile and run that code while running 2.6.12 from cvs.  As I
previously mentioned, I tested the offending code on a kernel I compiled
from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.

-Steve

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Maciej W. Rozycki]

On Fri, 1 Jul 2005, Daniel Jacobowitz wrote:

> Sure - send them to me, or better yet, put them in bugzilla and make
> sure you copy me.  I can't promise you timely response just now because
> I'm about twelve feet under on this current project at work, but I'll
> do everything I can.

 OK, one is already there as bug #933 and I'll add the rest.

> We're going to have automated MIPS regression testing sometime this
> year, too.

 Oh, that would be most welcome.

  Maciej

RE: Seg fault when compiled with -mabi=64 and -lpthread

[Bryan Althouse]

Thanks for everyone's input!

Looks like I should upgrade glibc, and possibly gcc.  When you say that I
should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
the linux-mips.org CVS and the closest thing I can find is libc, and it
looks really old.  I have also found a glibc CVS at
:pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
this the "CVS HEAD"?  

Should I get GCC from the generic GCC site, or should get it from the
linux-mips CVS?  

I apologize for the simple questions.  I have not built a tool chain before.
I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
these sources for MIPs?

Bryan  

-----Original Message-----
From: Daniel Jacobowitz [mailto:dan@debian.org] 
Sent: Thursday, June 30, 2005 11:51 PM
To: Stephen P. Becker
Cc: Ralf Baechle; Bryan Althouse; 'Linux/MIPS Development'
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread

On Thu, Jun 30, 2005 at 06:09:09PM -0400, Stephen P. Becker wrote:
> 
> > Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> > I don't know how well that works nowadays; but current CVS versions do
> > work, or did when I last tested (a month or two ago).
> > 
> 
> Hmm, well with respect to my problem, I'm using a pretty recent
> toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> Bryan's segfault, but could not.  That code ran without error when I
> linked with libpthread.  Any thoughts?

I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
in a long time.  Try CVS HEAD of glibc instead.

Other than that, you're on your own - building glibc is extremely error
prone.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: Seg fault when compiled with -mabi=64 and -lpthread

[Bryan Althouse]

Thanks for everyone's input!

Looks like I should upgrade glibc, and possibly gcc.  When you say that I
should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
the linux-mips.org CVS and the closest thing I can find is libc, and it
looks really old.  I have also found a glibc CVS at
:pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
this the "CVS HEAD"?  

Should I get GCC from the generic GCC site, or should get it from the
linux-mips CVS?  

I apologize for the simple questions.  I have not built a tool chain before.
I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
these sources for MIPs?

Bryan  

-----Original Message-----
From: Daniel Jacobowitz [mailto:dan@debian.org] 
Sent: Thursday, June 30, 2005 11:51 PM
To: Stephen P. Becker
Cc: Ralf Baechle; Bryan Althouse; 'Linux/MIPS Development'
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread

On Thu, Jun 30, 2005 at 06:09:09PM -0400, Stephen P. Becker wrote:
> 
> > Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> > I don't know how well that works nowadays; but current CVS versions do
> > work, or did when I last tested (a month or two ago).
> > 
> 
> Hmm, well with respect to my problem, I'm using a pretty recent
> toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> Bryan's segfault, but could not.  That code ran without error when I
> linked with libpthread.  Any thoughts?

I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
in a long time.  Try CVS HEAD of glibc instead.

Other than that, you're on your own - building glibc is extremely error
prone.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Maciej W. Rozycki]

On Fri, 1 Jul 2005, Stephen P. Becker wrote:

> I'm sure it can be error prone, but that isn't the problem here at all.
>   My n32 glibc 2.3.5 compiled and seems to work just fine, and I was
> able to compile an entire userland around it that has no (other)
> problems so far as I can tell.  By this, I mean "emerge system" in
> Gentoo terms, which is a pretty good test of whether the toolchain works
> or not.  Furthermore, other programs that are linked against libpthread
> run without causing a segfault and oops.  I'm talking about glib, as in
> the glib that used to be part of GTK+ before it was split out some time
> ago.
> 
> The segfault with kernel oops that I can't get around occurs while
> glib's configure script is checking for libpthread.  Specifically, it
> links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
> libpthread and then runs it.

 And libpthread is part of glibc, not glib.  So if an autoconf test (which 
I'm assuming is AC_CHECK_LIB() rather than a hand-crafted hack) breaks on 
running a program linked against libpthread, then it's not a problem with 
glib, but probably with either glibc or the toolchain used.

> I've somewhat convinced myself this is either a kernel and/or a header
> problem.  It seems I'm only able to reproduce this problem when trying
> to compile and run that code while running 2.6.12 from cvs.  As I
> previously mentioned, I tested the offending code on a kernel I compiled
> from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.

 If you get an Oops when running software as non-root, then it's a kernel 
bug, no matter what.

  Maciej

RE: Seg fault when compiled with -mabi=64 and -lpthread

[Maciej W. Rozycki]

On Fri, 1 Jul 2005, Bryan Althouse wrote:

> Looks like I should upgrade glibc, and possibly gcc.  When you say that I
> should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
> the linux-mips.org CVS and the closest thing I can find is libc, and it
> looks really old.  I have also found a glibc CVS at
> :pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
> this the "CVS HEAD"?  

 Yes, just pull the tree without any tags.

> Should I get GCC from the generic GCC site, or should get it from the
> linux-mips CVS?  

 The latest GCC 3.4.x should probably be OK, but if you want 4.x, then 
just get the latest release from (your closest mirror of) ftp.gnu.org -- 
if you don't rush, that may be 4.0.1.

> I apologize for the simple questions.  I have not built a tool chain before.
> I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
> these sources for MIPs?

 It depends on whether you trigger any bugs.

  Maciej

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Stephen P. Becker]

>>The segfault with kernel oops that I can't get around occurs while
>>glib's configure script is checking for libpthread.  Specifically, it
>>links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
>>libpthread and then runs it.
> 
> 
> And libpthread is part of glibc, not glib.  So if an autoconf test (which 
> I'm assuming is AC_CHECK_LIB() rather than a hand-crafted hack) breaks on 
> running a program linked against libpthread, then it's not a problem with 
> glib, but probably with either glibc or the toolchain used.

I'm aware of this. It just sounded like Daniel was questioning whether
or not my glibc was compiling/working in the first place.

>>I've somewhat convinced myself this is either a kernel and/or a header
>>problem.  It seems I'm only able to reproduce this problem when trying
>>to compile and run that code while running 2.6.12 from cvs.  As I
>>previously mentioned, I tested the offending code on a kernel I compiled
>>from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.
> 
> 
>  If you get an Oops when running software as non-root, then it's a kernel 
> bug, no matter what.
> 

Yes, it certainly happens when running as a non-privileged user.  If I
get a bit of time later today, I was going to try and track down which
cvs commit and/or kernel version broke things.

-Steve

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Daniel Jacobowitz]

On Fri, Jul 01, 2005 at 10:56:17AM -0400, Stephen P. Becker wrote:
> The segfault with kernel oops that I can't get around occurs while
> glib's configure script is checking for libpthread.  Specifically, it
> links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
> libpthread and then runs it.

If that oopses, your famed emerge testing hasn't run any threaded
programs, my friend :-)

Could be kernel, could be library, could be both.  Must be at least
kernel because the kernel should never oops.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Seg fault when compiled with -mabi=64 and -lpthread

[Stephen P. Becker]

Daniel Jacobowitz wrote:
> On Fri, Jul 01, 2005 at 10:56:17AM -0400, Stephen P. Becker wrote:
> 
>>The segfault with kernel oops that I can't get around occurs while
>>glib's configure script is checking for libpthread.  Specifically, it
>>links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
>>libpthread and then runs it.
> 
> 
> If that oopses, your famed emerge testing hasn't run any threaded
> programs, my friend :-)

What do you mean by "famed" emerge testing?  In any case, that is what I
am in the process of doing (testing).  This userland I am working with
is in no way an official Gentoo install. :)  At some point in the
future, we will probably make official n32 install stages available to
the general users, after we work all the bugs out...this just happens to
be one of those bugs.

> Could be kernel, could be library, could be both.

Well, since you say that glibc 2.3.5 probably isn't up to par for
mips64, I'll see if I can get cvs HEAD going in a chroot and see if that
fixes the problem.

> Must be at least kernel because the kernel should never oops.

Agreed.

-Steve