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 <[email protected]> wrote: > Eugene Rudoy <[email protected]> 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 >
--- sysdeps/linux-gnu/mips/plt.c +++ sysdeps/linux-gnu/mips/plt.c @@ -236,9 +236,6 @@ } } - /* 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; }
--- read_config_file.c +++ read_config_file.c @@ -24,7 +24,7 @@ /* getline is POSIX.1-2008. It was originally a GNU extension, and * chances are uClibc still needs _GNU_SOURCE, but for now try it this * way. */ -#define _POSIX_C_SOURCE 200809L +#define _GNU_SOURCE #include "config.h" --- sysdeps/linux-gnu/hooks.c +++ sysdeps/linux-gnu/hooks.c @@ -18,7 +18,7 @@ * 02110-1301 USA */ -#define _POSIX_C_SOURCE 200809L +#define _GNU_SOURCE #include <sys/types.h> #include <alloca.h> #include <errno.h>
_______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
