[Ltrace-devel] missing library traces

[Sedat Dilek]

[ CC Edgar and Oliver ]

I remember Edgar and Oliver were helpul on parts of MIPS(EL).
IIRC Oliver did also test with Freetz in QEMU/VM.

Maybe they are willing to help, for example how to setup Freetz, etc.

BTW, just for the sake of correctness...
Can you give Oliver appropriates credits in CREDITS file?
Thanks.
( I liked his conversion/consolidation/simplification for MIPSEL. )

- Sedat -

[1] http://anonscm.debian.org/cgit/collab-maint/ltrace.git/log/?qt=author&q=Oliver+Spornitz

On Mon, Jan 5, 2015 at 5:15 PM, Petr Machata <pmachata at redhat.com> wrote:
> 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