[Ltrace-devel] missing library traces

[Eugene Rudoy]

Hi Petr,

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).

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)?

Best,
Gene


On Thu, Jan 16, 2014 at 7:59 PM, Petr Machata <pmachata at redhat.com> wrote:

> Eugene Rudoy <gene at freetz.org> writes:
>
> >> It might be a missing feature.  ltrace generally relies on existence of
> >> PLT slots, through which all call to dynamic libraries are made.  We put
> >> breakpoints to these slots, so as to catch these calls.  If there are no
> >> PLT slots, we can't trace library calls.
> >
> > hmm, was it done some other way in (the now ancient) ltrace-0.5.3?
> > ltrace-0.5.3 works just fine with exactly the same binary.
>
> The following might be what we are missing now:
>
> -#ifdef __mips__
> -               // MIPS doesn't use the PLT and the GOT entries get changed
> -               // on startup.
> -               for(i=lte->mips_gotsym; i<lte->dynsym_count;i++){
> [...]
>
> But there seems to be a kinda-sorta replacement of that in
> sysdeps/linux-gnu/mips/plt.c:
>
>         /* Tell the generic code how many dynamic trace:able symbols
>          * we've got.  */
>         lte->relplt_count = lte->dynsym_count - lte->arch.mips_gotsym;
>         return 0;
>
> And overall there seems to be a lot of business going on in the MIPS'
> plt.c about GOT entries, so it seems it all should have been properly
> migrated.  I dunno.  Possibly it's different code that made 0.5 trace
> those -mno-plt calls.
>
> > I've also tested the latest master - doesn't work either.
>
> I'm surprised you even compiled it.  The above lte->relplt_count line
> that I cite should fail to compile in current master.  We now keep a
> vector of all PLT-like relocations instead.  The motivation for this
> change was a support for local IFUNC calls on PowerPC.  Those use
> relocations that are stored in a separate section, so the core musn't
> assume it all comes from e.g. .rela.plt anymore.  Instead we now have a
> vector that's primed from the usual .rela.plt, but backends are free to
> add to it.
>
> It shouldn't be hard for MIPS' arch_elf_init to add any special entries
> it needs to that vector to support tracing of -mno-plt calls.  They
> would then get routed through arch_plt_sym_val and arch_elf_add_plt_entry
> as any other relocation, and the backend could do its thing about them.
>
> If there are no actual relocations in the ELF file to add to the vector,
> it should be possible to just invent one, give it some code so that the
> backend can later tell it from the rest, and just add it to the vector
> like any other.
>
> Thanks,
> PM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20140116/c890a2c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 330-undeclared_relplt_count.patch
Type: text/x-patch
Size: 262 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20140116/c890a2c6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 340-uclibc_requires_GNU_SOURCE.patch
Type: text/x-patch
Size: 520 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20140116/c890a2c6/attachment-0001.bin>