#ltrace

Another Linux shared library trace facility

I previously blogged about a way to force ltrace to show some shared memory trace records that didn’t show up by default.

Where that fails to be useful, is when you don’t have a guess about what shared library the code in question lives in. I just blundered on the latracecommand that uses a Linux dynamic loader audit facility to give a complete trace of all the function-name/library-name pairs…

using ltrace to dig into shared libraries

I was trying to find where the clang compiler is writing out constant global data values, and didn’t manage to find it by code inspection. If I run ltrace (also tracing system calls), I see the point where the ELF object is written out:

std::string::compare(std::string const&) const(0x7ffc8983a190, 0x1e32e60, 7, 254) = 5 std::string::compare(std::string const&) const(0x1e32e60, 0x7ffc8983a190,…