Re: [Libunwind-devel] Testing time

[Lassi Tuura]

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