[Ltrace-devel] missing library traces

[Sedat Dilek]

On Fri, Jan 2, 2015 at 1:54 PM, Petr Machata <pmachata at redhat.com> wrote:
> 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 for taking care.

Unfortunately, I don't use my Freetz-modded routers anymore (using 3G
UMTS/HSPA).
Offhand, I cannot tell you how to test MIPS stuff here (I was used to
test on bare metal).

What are your plans?
Do you plan to (cherry-)pick your changes for ltrace-0.7?

Can you please add a note about current situation on MIPS, e.g. in the
TODO (I haven't checked it)?

Have more fun in 2015.

- Sedat -

P.S.: I will point that guy who asked me about ltrace on MIPS to the
ltrace ML-archive.