[Ltrace-devel] missing library traces

[Petr Machata]

Sedat Dilek <sedat.dilek at gmail.com> writes:

> On Thu, Jan 16, 2014 at 9:20 PM, Petr Machata <pmachata at redhat.com> wrote:
>> Eugene Rudoy <gene at freetz.org> writes:
>>
>>> as to compiling the master: I had to apply the two patches attached to this
>>> mail in order to compile it (I simply removed that
>>> "lte->relplt_count"-line).
>>
>> Hmm, the _GNU_SOURCE ones probably make sense (see the comment about
>> uclibc above one of them).

I pushed the _GNU_SOURCE patch to master now.

>>> As to fixing the issue, in particular "It shouldn't be hard for MIPS'
>>> arch_elf_init to add any special entries....": sounds interesting ;-) but
>>> it's something completely new to us (Oliver & me), we just cross-compile
>>> ltrace and make it available to the users of freetz-project.
>>>
>>> Would that be possible for you to take a deeper look into the issue? Is
>>> there something we can do to support you? Testing, hardware (probably
>>> remote access only)?
>>
>> In fact I'm installing Debian Wheezy inside Qemu as I write this.
>> I can't promise anything (this would have to go from my personal time
>> budget, which is already fairly strained), but I should be able to at
>> least take a look.
>>
>
> Recently, I was asked some questions about ltrace-0.7.3 MIPS cross-compilation.
>
> What happened with this issue?
> Is ltrace-0.7.y still BROKEN on MIPS?
>
> I have seen a "pmachata/mips" Git branch with a patch called "Support
> tracing of PLT-less MIPS binaries" on top... which has not entered
> master.

So yeah, I spent some time on that (possibly the weekend and then a
couple evenings before 2014-01-21).  Looking into my notes, I needed to
move on to Aarch64 support, and the MIPS work must have gradually
slipped my mind.

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.

Thanks,
Petr