[Ltrace-devel] ltrace v0.7.0-git: Session on a Freetz MIPSEL router box

[Petr Machata]

"Jackie Yeh [葉龍泉]" <jackieontravel at gmail.com> writes:

> Per my private conversation with Sedat, the latest ltrace version
> (0.7.0-gitf97b187) workw fine on his side with freetz.
>
> However in my environment this version for MIPSEL STB still doesn't
> work. Here is some running log:

> DEBUG: breakpoints.c:366: breakpoints_init(pid=957)
> DEBUG: ltrace-elf.c:339: do_init_elf(filename=/proc/957/exe)
> DEBUG: ltrace-elf.c:340: Reading ELF from /proc/957/exe...
> DEBUG: ltrace-elf.c:496: /proc/957/exe 4 PLT relocations
> DEBUG: ltrace-elf.c:508: do_close_elf()
> DEBUG: proc.c:807: proc_add_breakpoint(pid=957, (null)@0x400640)
> DEBUG: dict.c:158: dict_find_entry()
> DEBUG: dict.c:98: dict_enter()
> DEBUG: dict.c:124: new dict entry at 0x4e2eb8[528]: (0x400640,0x4bc548)
> DEBUG: breakpoint.c:85: enable_breakpoint: pid=957, addr=0x400640, symbol=(null)
> DEBUG: breakpoint.c:48: arch_enable_breakpoint: pid=957, addr=0x400640, symbol=(null)
> DEBUG: proc.c:733: added library a.out_freetz at 0x400000 (./a.out_freetz) to 957

So you have 4 PLT relocations, but then no breakpoints are enabled.
Strange.  Of course on MIPS we create them delayed, but...

> DEBUG: events.c:334: event: BREAKPOINT: pid=957, addr=0x400640

e_entry breakpoint hits, and this should eventually lead to
arch_dynlink_done, which, on MIPS, enables those symbols.  But before
that happens, we need to crawl linkmap:

> DEBUG: dict.c:132: dict_remove(0x400640)
> DEBUG: proc.c:566: linkmap_init()
> DEBUG: proc.c:324: find_dynamic_entry()
> DEBUG: proc.c:522: load_debug_struct
> DEBUG: breakpoints.c:73: address2bpstruct(pid=957, addr=0x400640)

This doesn't look right.  We should see insert_breakpoint with address
of r_debug.r_brk.  We don't know the details, because -D71 is not
enough, -D77 is necessary for that (this is undocumented :-/ ).

So, ltrace finds DT_DEBUG, and tries to load_debug_struct, but then
presumably umovebytes fails.  Somone would need to look at this on live
machine.  The following patch might be of help in figuring out what
happened:

diff --git a/sysdeps/linux-gnu/proc.c b/sysdeps/linux-gnu/proc.c
index d05da13..1df15d3 100644
--- a/sysdeps/linux-gnu/proc.c
+++ b/sysdeps/linux-gnu/proc.c
@@ -413,8 +413,11 @@ static int
 fetch_rd64(struct Process *proc, arch_addr_t addr,
 	   struct lt_r_debug_64 *ret)
 {
-	if (umovebytes(proc, addr, ret, sizeof(*ret)) != sizeof(*ret))
+	if (umovebytes(proc, addr, ret, sizeof(*ret)) != sizeof(*ret)) {
+		fprintf(stderr, "fetch_rd64: couldn't read %zd bytes from %p\n",
+			sizeof(*ret), addr);
 		return -1;
+	}
 	return 0;
 }
 
@@ -423,8 +426,11 @@ fetch_rd32(struct Process *proc, arch_addr_t addr,
 	   struct lt_r_debug_64 *ret)
 {
 	struct lt_r_debug_32 rd;
-	if (umovebytes(proc, addr, &rd, sizeof(rd)) != sizeof(rd))
+	if (umovebytes(proc, addr, &rd, sizeof(rd)) != sizeof(rd)) {
+		fprintf(stderr, "fetch_rd32: couldn't read %zd bytes from %p\n",
+			sizeof(rd), addr);
 		return -1;
+	}
 
 	ret->r_version = rd.r_version;
 	ret->r_map = rd.r_map;
~~

Anyway, ltrace never reads the link map, but that shouldn't prevent
tracing main binary.  But apparently the PLT symbols from main binary
are never activated.  I don't understand why.  Someone with a live MIPS
system handy would again need to tinker with it.  The following patch
might be handy:

diff --git a/proc.c b/proc.c
index 3dab1e2..9abfc55 100644
--- a/proc.c
+++ b/proc.c
@@ -636,8 +636,11 @@ breakpoint_for_symbol(struct library_symbol *libsym, struct Process *proc)
 	assert(proc->leader == proc);
 
 	/* Don't enable latent or delayed symbols.  */
-	if (libsym->latent || libsym->delayed)
+	if (libsym->latent || libsym->delayed) {
+		debug(DEBUG_FUNCTION, "Not enabling inactive symbol (%d,%d)",
+		      libsym->latent, libsym->delayed);
 		return 0;
+	}
 
 	bp_addr = sym2addr(proc, libsym);
 
~~

I will add both these patches to master.

Thanks,
PM