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: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 1 Jul 2005 16:22:19 +0100 (BST)
Cc: Daniel Jacobowitz <dan@debian.org>, Ralf Baechle <ralf@linux-mips.org>, Bryan Althouse <bryan.althouse@3phoenix.com>, "'Linux/MIPS Development'" <linux-mips@linux-mips.org>
In-reply-to: <42C55991.70109@gentoo.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <42C55991.70109@gentoo.org>
Sender: linux-mips-bounce@linux-mips.org
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

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