More on the armv4l segfault.

Paul Brook paul at codesourcery.com
Fri Dec 15 03:31:05 UTC 2006


On Friday 15 December 2006 03:05, Rob Landley wrote:
> On Thursday 14 December 2006 8:17 pm, Rob Landley wrote:
> > On Thursday 14 December 2006 7:50 pm, Rob Landley wrote:
> > > I think I've narrowed it down to the 16825/16827 pair.  If I add 16821
> > > and 16826, it works.  If I add 16823 to that, it still works.  If I add
> > > 16825
>
> to
>
> > > that, I get a toolchain that fails to link.  (Whether or not I
> > > add -lpthread.)  If I add 16827, I get the segfault on exit.
> > >
> > > So 16825/16827 is breaking armv4l.
>
> Ok, the fix is to take weak_function off of __pthread_mutex_unlock in
> ulibc_pthread.h.  I have no idea _why_ that fixes it, but it does.
>
> If the prototype says that __pthread_mutex_unlock() is weak, then
> __uclibc_mutex_unlock() never gets called (I've stuck write(2,blah)
> commands in it and they don't happen).  Instead I get a segfault on exit. 
> But if I take the weak off, then it's called four times (and the call makes
> it down to __pthread_return_0().)
>
> I'm not quite sure what's going on here.  If __pthread_mutex_unlock() is
> _not_ prototyped as a weak symbol, _then_ it winds up calling
> __pthread_return_0(); I'm confused.  (This is gcc 4.1.1 with binutils 2.17
> building for armv4l.)

Sounds like something is unconditionally calling __pthread_mutex_unlock() 
without making sure it is pulled into the binary (calling a weak symbol that 
is not defined will cause a segfault).

Paul



More information about the uClibc mailing list