[Ltrace-devel] missing library traces

[Petr Machata]

Faraz Shahbazker <Faraz.Shahbazker at imgtec.com> writes:

> On Fri, Jan 2, 2015 at 1:54 PM, Petr Machata <pmachata at redhat.com> wrote:
>> It seems like I wanted to redo what PowerPC (and newly Xtensa!) was/is
>> doing with unresolving PLT slots when they are resolved, so that we
>> don't have to move breakpoints to function entry points, but can keep
>> them in PLT.  I'm not sure how far I got.  The code for this
>> specifically seems to be in, but it is likely that I broke some other
>> MIPS use cases, special symbol types or other MIPS magic.
>>
>> Someone would need to fix regressions in test cases between
>> pmachata/mips and 94773bf0b1 (the branch-off point) and fix them.  They
>> would need to have enough domain knowledge to realize where the test
>> suite has blind spots, what it doesn't test, and add tests and fixes for
>> these test cases.  That someone is unlikely to be me, my personal time
>> budget is actually even more strained now than it was a year ago.
>
> Just started looking at your branch before the holidays. The
> 'unresolve' logic for pre-linked ELFs is missing

Yeah, now that I'm looking it, you're right, unprelink isn't written.
The necessary data is stored to libsym->arch.data->got_entry_value and
libsym->arch.data->stub_addr.  The former is what's in the GOT entry now
(i.e. the resolved value, the address of the function entry point), the
latter is what should be there (or rather, what ltrace wants there to be
so that tracing works).  Calling unresolve_got_entry and
mark_as_resolved in mips_stub_bp_install may be all that's needed.

You will probably also need to fill in mips_stub_bp_retract, so that
when ltrace detaches, you patch things back up the way they were.  At
least on PowerPC this was necessary--prelinking modified the binary such
that the normal dynamic resolution path didn't work, and when a call was
made through an unresolved slot, the process would crash.  So you need
to un-unresolve everything again.

> and some of the calculations need to be biased appropriately. I don't

Hmm, that's quite possible.  This is a perennial source of problems.
Really we should type biased and unbiased addresses differently, but C
is not a good language for these sorts of abstractions.

> have the necessary domain knowledge, but I do have time, so if someone
> could nudge me in the right direction ...

I don't really know much about MIPS either.  Mostly what helped me
figure this stuff out was staring at objdump -d, eu-readelf and memory
dumps in gdb.  Which is to say that I'm not sure how much help I'll be.
But do ask, we should be able to figure this out.

Thanks,
Petr