[Ltrace-devel] Tracing library calls on PowerPC

[Petr Machata]

Petr Machata <pmachata at redhat.com> writes:

> there doesn't seem to be any way to reliably compute addresses of
> stubs.  There are symbols for stubs in symbol table, but that goes
> away when stripped [...]  We might still use them if they are in
> symbol table [...]

This is implemented on pmachata/libs branch.  The case of multiple stubs
should be supported, but wasn't tested.

> So when a process is started, we do two things: inspect .plt section,
> and put breakpoints to PLT entries (that we compute like in PPC32).
>
> If the binary was prelinked, .plt is filled with addresses.  We remember
> those and rewrite them to point to PLT entries instead.  When a call is
> made, the corresponding PLT breakpoint hits.  We don't even bother
> removing and re-enabling the breakpoint, instead we simply move the IP
> to the previously-remembered address.

This is now implemented as well.

> The .plt changes should be undone before a process is detached, but
> even if they are not, the worst that happens is that those symbols are
> resolved again.

Note that this is not true.  The dynamic linker doesn't initialize .plt
of prelinked binary at all, but prelink leaves the first two entries
zero (they are not needed in prelinked binary).  But the resolver needs
sensible values in those two entries.  Se we do have to undo the
changes.  But that is not new, we already have to retract breakpoints.

> If the binary was not prelinked, we need to smuggle a breakpoint
> somewhere where it hits every time that .plt is updated: a post-fixup
> breakpoint.  [...] Yet another way is to single-step the process
> through the resolver and watch for changes in .plt.  That seems as the
> most robust solution.

This is implemented, and seems to basically work, but the process gets
stuck single-stepping for some reason.  I might be doing something
wrong, or else the kernel is buggy.  If the latter is the case, I may
need to rewrite this to use some other post-fixup scheme, because if
this doesn't work on a range of kernels, then we simlpy can't use it,
whether or not it _should_ work.

> The whole resolver gambit has to be handled the same way that breakpoint
> re-enablement in a multi-threaded processes is: when PLT breakpoint hits
> the first time, we stop all threads before proceeding.

This code is shared with the multi-threaded process stopping machinery.
Here's hoping that I didn't break the latter, because it was rather
difficult to get right and debug.

I'm sure there's a juicy debug session ahead of me, but the whole deal
seems to be working overall.

Thanks,
PM