<div dir="ltr">Hi Petr,<div><br></div><div>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).</div><div><br>
</div>
<div>As to fixing the issue, in particular "<span style="font-family:arial,sans-serif;font-size:13px">It shouldn't be hard for MIPS' arch_elf_init to add any special entries....</span><span style="font-size:13px;font-family:arial,sans-serif">":</span> 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.</div>
<div><br></div><div>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)?</div><div><br></div><div>Best,</div><div>
Gene</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 7:59 PM, Petr Machata <span dir="ltr"><<a href="mailto:pmachata@redhat.com" target="_blank">pmachata@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Eugene Rudoy <<a href="mailto:gene@freetz.org">gene@freetz.org</a>> writes:<br>
<br>
>> It might be a missing feature.  ltrace generally relies on existence of<br>
>> PLT slots, through which all call to dynamic libraries are made.  We put<br>
>> breakpoints to these slots, so as to catch these calls.  If there are no<br>
>> PLT slots, we can't trace library calls.<br>
><br>
> hmm, was it done some other way in (the now ancient) ltrace-0.5.3?<br>
> ltrace-0.5.3 works just fine with exactly the same binary.<br>
<br>
</div>The following might be what we are missing now:<br>
<br>
-#ifdef __mips__<br>
-               // MIPS doesn't use the PLT and the GOT entries get changed<br>
-               // on startup.<br>
-               for(i=lte->mips_gotsym; i<lte->dynsym_count;i++){<br>
[...]<br>
<br>
But there seems to be a kinda-sorta replacement of that in<br>
sysdeps/linux-gnu/mips/plt.c:<br>
<br>
        /* Tell the generic code how many dynamic trace:able symbols<br>
         * we've got.  */<br>
        lte->relplt_count = lte->dynsym_count - lte->arch.mips_gotsym;<br>
        return 0;<br>
<br>
And overall there seems to be a lot of business going on in the MIPS'<br>
plt.c about GOT entries, so it seems it all should have been properly<br>
migrated.  I dunno.  Possibly it's different code that made 0.5 trace<br>
those -mno-plt calls.<br>
<div class="im"><br>
> I've also tested the latest master - doesn't work either.<br>
<br>
</div>I'm surprised you even compiled it.  The above lte->relplt_count line<br>
that I cite should fail to compile in current master.  We now keep a<br>
vector of all PLT-like relocations instead.  The motivation for this<br>
change was a support for local IFUNC calls on PowerPC.  Those use<br>
relocations that are stored in a separate section, so the core musn't<br>
assume it all comes from e.g. .rela.plt anymore.  Instead we now have a<br>
vector that's primed from the usual .rela.plt, but backends are free to<br>
add to it.<br>
<br>
It shouldn't be hard for MIPS' arch_elf_init to add any special entries<br>
it needs to that vector to support tracing of -mno-plt calls.  They<br>
would then get routed through arch_plt_sym_val and arch_elf_add_plt_entry<br>
as any other relocation, and the backend could do its thing about them.<br>
<br>
If there are no actual relocations in the ELF file to add to the vector,<br>
it should be possible to just invent one, give it some code so that the<br>
backend can later tell it from the rest, and just add it to the vector<br>
like any other.<br>
<br>
Thanks,<br>
PM<br>
</blockquote></div><br></div>