linux-mips
[Top] [All Lists]

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

To: "'Stephen P. Becker'" <geoman@gentoo.org>
Subject: RE: Seg fault when compiled with -mabi=64 and -lpthread
From: "Bryan Althouse" <bryan.althouse@3phoenix.com>
Date: Thu, 30 Jun 2005 15:31:36 -0400
Cc: "'Linux/MIPS Development'" <linux-mips@linux-mips.org>
In-reply-to: <42C44336.1080401@gentoo.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcV9pz+aRx+9hWzVTzilb9rL9PauPgAAlkvQ
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


<Prev in Thread] Current Thread [Next in Thread>