[Ltrace-devel] [PATCH] add library path to stack trace output when using -w

[Petr Machata]

Luca Clementi <luca.clementi at gmail.com> writes:

> On Mon, Sep 30, 2013 at 5:17 AM, Petr Machata <pmachata at redhat.com> wrote:
>> Luca Clementi <luca.clementi at gmail.com> writes:

> I also forgot to
> #ifdef HAVE_LIBUNWIND

Hmm, right, you would probably get warnings about unused static
functions.

>> [...] you assume that PT_DYNAMIC will be mapped after any LOAD
>> segments--do you think we can rely on that?
>
> Honestly I don't know enough linker internals to say that.
>
> I just did some empirical tests on Centos5/6 and on Ubuntu 12.x (that
> uses the new Gold linker).

Hmm, the trouble is that this is generic code.  Currently the only
ltrace backend is for GNU/Linux, but there were people looking for
FreeBSD and Android ports.  And I don't even know what toolchain they
use for all those MIPS microcontrollers, where ltrace was ported.

> It would be safe to store the length of library from the base in the
> library struct.
> Although I think that at least theoretically, you could have several
> PT_LOAD executable segments which are not adjacent, so if you really
> want to be paranoid you should have a list of:

So, how about assuming that everything above the base of a given library
belongs to that library.  That would give us some false positives for
out-of-bounds IP's, but those are results of a bug anyway.  You'd do one
pass through the libraries, looking for the one that has its base
closest to the given IP (but below it).  It's a bit of a hack, but would
be much simpler than keeping around lists of PT_LOAD +x segments, and
still get the work done for cases where IP is valid.

Thanks,
PM