[Ltrace-devel] missing library traces

[Petr Machata]

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