[Ltrace-devel] ltrace on ppc32 [Was: Re: ltrace is_weak patch]

[Petr Machata]

On Mon, 2006-08-28 at 17:12 +0200, Petr Machata wrote:
> Anyway, more ltrace bugs appeared on ppc32, that seem to be related to
> the one I was targeting with my fix.  E.g., have this program:

Another lengthy soliloquy on the way.  I found why ltrace breaks on
ppc32.  The problem is that wrong addresses get picked out from elf.  

According to objdump, .plt contains this:

    10010a40:       10 00 08 60     # getpid
    10010a44:       10 00 08 64     # gmon_start
    10010a48:       10 00 08 68     # libc_start
    10010a4c:       10 00 08 6c     # printf

On the adresses 860..86c, there are four NOPs (suspiciously near each
other, considering plt relocation should be here).  Placing breakpoints
to these addresses completely derails ltrace.  It seems that nops are
part of normal code flow, so spurious breakpoints appear as the thread
of execution passes this place.

The .dynsym contains this:
    10000194 <.dynsym>:
    100001b8:       10 00 08 20     vmhaddshs v0,v0,v1,v0 # getpid
    100001c8:       10 00 08 f8     .long 0x100008f8      # gmon_start
    100001d8:       10 00 08 50     mulhhw  r0,r0,r1      # printf
    100001e8:       10 00 08 40     vadduhm v0,v0,v1      # libc_start

The contents of 820..860, on the other hand, look quite promising:

    10000820:       3d 60 10 01     lis     r11,4097
    10000824:       81 6b 0a 40     lwz     r11,2624(r11)
    10000828:       7d 69 03 a6     mtctr   r11
    1000082c:       4e 80 04 20     bctr
    # and more of similar

Indeed, assigning the breakpoint addresses ahead-of-time with the use of
symbol value (addr = sym.st_value, and behaving as if plt was EXEC), as
opposed to ptracing from plt (addr = rela.r_offset, and plt POINT) fixes
the ltrace.  Now what... is there a problem in toolchain, or is ppc
supposed to behave this way?  Maybe that NOPs get translated to
something different later on... don't really know here.

I'm attaching the patch.  I don't know if I'm solving the problem at the
right place at all.  And the patch has hairs of its own, e.g. -l is
broken.  But the testsuite is now much more happy.  I'll continue
tomorrow.

PM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-0.5-ppc32-2.patch
Type: text/x-patch
Size: 920 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20060830/a6155e4c/ltrace-0.5-ppc32-2.bin