[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Testing time
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] Testing time |
Date: |
Wed, 30 Mar 2011 07:49:22 +0200 |
Hi,
>> 1) The new slow_backtrace() does its own unw_getcontext(). Will this not
>> introduce one extra stack level if slow_backtrace() isn't inlined into
>> backtrace()? OTOH, if it's inlined, why split? In my builds it is always
>> inlined.
>
> slow_backtrace() is marked ALWAYS_INLINE. I did it this way to keep
> the fast/slow unwind paths logically separate.
Yes ALWAYS_INLINE would be fine. Could you add that to the code?
http://git.savannah.gnu.org/gitweb/?p=libunwind.git&a=search&h=HEAD&st=grep&s=ALWAYS_INLINE
>> 2) I still can't get our library to call into libunwind's backtrace()
>> function. If I read LD_DEBUG=symbols output correctly, libc.so is searched
>> for 'backtrace' always, before libunwind.so. I think we need a distinct
>> symbol. I checked this both with our library ($LD_PRELOAD'ed into
>> executables, depends on libunwind), and libunwind 'make check' test
>> programs. In all cases 'backtrace' comes from libc.so.
>
> I believe the history of backtrace() in libunwind is that on Itanium,
> libunwind was the main provider of the unwind/backtrace functionality
> including backtrace(). Someone more current with Itanium should be
> able to comment on this.
>
> Also, I'm not sure why you're not able to access libunwind's version
> of backtrace(). Ltest-trace seems to work fine for me. [...]
Hm, not getting backtrace() used from libunwind in 'make check' must have been
a driver error. In a clean tree I do see backtrace() calls go to libunwind.
My guess is I played with this and didn't properly rebuild. I did verify
LD_DEBUG
and in gdb it definitely picked up libc version. My guess is that I hadn't done
a proper rebuild somehow - I noticed at one point 'make check' doesn't rebuild
libunwind, only the test programs, which may have tripped me here. At any rate
I can't repeat that behaviour now.
> libc defines backtrace() as a weak symbol which should make it easy to
> override via LD_PRELOAD.
Unfortunately it doesn't, at least not on the system I use here (RHEL5-based).
It would work if backtrace() definition was in libigprof.so, not in one of its
dependencies. The search order is the application, then the pre-loaded library,
then the app's shared library dependencies, and only then the pre-loaded lib
dependencies. Of course the app always has libc...
Here is build with igprof calling backtrace(), backtrace defined in libunwind
as per current git head, when running 'ls' with LD_PRELOAD=libigprof.so:
$ LD_DEBUG=symbols igprof -mp ls |& grep backtrace
28383: symbol=backtrace; lookup in file=ls [0]
28383: symbol=backtrace; lookup in
file=/build/lat/igprof/install/lib/libigprof.so [0]
28383: symbol=backtrace; lookup in file=/lib64/librt.so.1 [0]
28383: symbol=backtrace; lookup in file=/lib64/libacl.so.1 [0]
28383: symbol=backtrace; lookup in file=/lib64/libselinux.so.1 [0]
28383: symbol=backtrace; lookup in file=/lib64/libc.so.6 [0]
And here's with unw_backtrace() instead:
$ LD_DEBUG=symbols igprof -mp ls |& grep backtrace
17592: symbol=unw_backtrace; lookup in file=ls [0]
17592: symbol=unw_backtrace; lookup in
file=/build/lat/igprof/install/lib/libigprof.so [0]
17592: symbol=unw_backtrace; lookup in file=/lib64/librt.so.1 [0]
17592: symbol=unw_backtrace; lookup in file=/lib64/libacl.so.1 [0]
17592: symbol=unw_backtrace; lookup in file=/lib64/libselinux.so.1 [0]
17592: symbol=unw_backtrace; lookup in file=/lib64/libc.so.6 [0]
17592: symbol=unw_backtrace; lookup in
file=/build/lat/igprof/install/lib/libunwind.so.7 [0]
(We tripped over this before, igprof picked up getenv() and unsetenv() inside
'sh' from the main binary, with rather different semantics than libc. Ugh.)
> I'll take a look at your patches hopefully in the next couple of days.
Thanks!
Regards,
Lassi
- Re: [Libunwind-devel] Testing time, (continued)
Re: [Libunwind-devel] Testing time, Ken Werner, 2011/03/28
Re: [Libunwind-devel] Testing time, Lassi Tuura, 2011/03/29
Re: [Libunwind-devel] Testing time, Lassi Tuura, 2011/03/29