problems with dlsym() on MIPS, looking for advice
I think this is a userspace/toolchain issue, so if that's offtopic for this list please let me know of a better resource.
We're using glibc 2.3.6 and gcc 3.4.4. We've got some library code (that gets preloaded for debugging) something like this:
ee_sigaction_fptr = dlsym(RTLD_DEFAULT, "sigaction");
if (ee_sigaction_fptr == sigaction)
ee_sigaction_fptr = dlsym(RTLD_NEXT, "sigaction");
We have declared our own sigaction procedure which is extern in this code. On non-MIPS arches (powerpc, x86, x86_64) the RTLD_DEFAULT call returns the address of our external procedure and the RTLD_NEXT call returns the real sigaction address in its appropriate library.
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.
We tried recoding the above debug code to do one DEFAULT call and a loop of NEXT calls until it returns NULL. It didn't. It just kept returning the last pointer all the time.
Has anyone seen anything like this? Is there a known issue with dlsym() and certain toolchains? (Maybe something like "http://busybox.net/lists/uclibc/2007-January/017150.html"?)
Any help you can provide would be appreciated.
Thanks,
Chris
Re: do-lookup.h regarding to mips/dlsym and libstdc++
Quoted 8 lines · Yoriko Komatsuzaki
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?
Quoted 8 lines · Chris Friesen
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_NEXTcall 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
Signature · 2 lines
Daniel Jacobowitz CodeSourcery
Re: do-lookup.h regarding to mips/dlsym and libstdc++
Thank you for your reply.
I will do the checking.
---
Yoriko Komatsuzaki ([email protected])
System Software Development Department
Common Technology Division
Technology Development Group
Sony Corporation
Quoted 34 lines · Yoriko Komatsuzaki
Quoted 8 lines
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?
Quoted 8 lines · Chris Friesen
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_NEXTcall 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.htmlSignature · 2 lines
Daniel Jacobowitz CodeSourcery