This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: do-lookup.h regarding to mips/dlsym and libstdc++
- From: Yoriko Komatsuzaki <yoriko at sm dot sony dot co dot jp>
- To: Daniel Jacobowitz <dan at debian dot org>
- Cc: Chris Friesen <cfriesen at nortel dot com>, libc-ports <libc-ports at sourceware dot org>, linux-mips at linux-mips dot org
- Date: Thu, 03 Jul 2008 14:05:54 +0900
- Subject: Re: do-lookup.h regarding to mips/dlsym and libstdc++
- References: <20080129132739.5D6B.YORIKO@sm.sony.co.jp> <20080702124722.GA15301@caradoc.them.org>
Thank you for your reply.
I will do the checking.
---
Yoriko Komatsuzaki (yoriko@sm.sony.co.jp)
System Software Development Department
Common Technology Division
Technology Development Group
Sony Corporation
> On Tue, Jan 29, 2008 at 01:32:20PM +0900, Yoriko Komatsuzaki wrote:
> > Because even though UNDEF symbol is found,
> > it can process as global symbol for the rare occasion.
> >
> > This phenomena is showed only in mips. When libstdc++ is linked in
> > proior libc, the malloc's entry in libstdc++ MIPS.stubs table seemed to
> > be recognized as the malloc global symbol ...
> >
> > How do you feel about it?
>
> On Mon, May 26, 2008 at 11:51:56AM -0600, Chris Friesen wrote:
> > On MIPS, the DEFAULT returns the address of this libraries undefined
> > symbol for the extern and NEXT returns our external procedure. Putting
> > in a second RTLD_NEXT call returned the real sigaction address.
> >
> > This worked for most procedures we are looking for. However, during
> > booting, we have an app that uses a specific library which has an extern
> > for sigaction as well and now in the preloaded code we need a fourth call
> > to dlsym to skip that one.
>
> Hi folks,
>
> This bug is fixed as a by-product of support for non-PIC MIPS
> executables. Either Richard's patch or CodeSourcery's, applied to
> glibc, should suffice. It'll be another week or two at least before
> they're applied to CVS, but in the mean time you can find them here:
>
> http://sourceware.org/ml/binutils/2008-06/msg00280.html
> http://sourceware.org/ml/binutils/2008-07/msg00008.html
>
> --
> Daniel Jacobowitz
> CodeSourcery
>