[Ltrace-devel] FC5 ltrace sigsegvs traced process on ppc

Petr Machata pmachata at redhat.com
Tue Jul 11 14:04:17 UTC 2006


Ian Wienand wrote:
> On Wed, Jun 14, 2006 at 01:20:19PM +0200, Petr Machata wrote:
> 
>>I had to bend it a little bit to compile it, NOP was defined only for
>>PPC64 mode.  Other than that:
> 
> 
> Ok, I'm not surprised as I took a bit of a guess.  Please feel free to
> check it in (with a ChangeLog entry :)

Will do.

>  
> 
>>I failed to mention that it's ppc problem in my previous report.  ppc64
>>version seems to work, it passes testsuite; ltrace built for ppc is
>>broken.
> 
> 
> I figured.  I don't have easy access to PPC linux at the moment so I'd
> be grateful if you could spare the time to have a look.

It took me quite some time to figure out what's going on.  Most of what
I found seems to be implicit knowledge around here, but they were new
things for me.

I managed to massage ltrace into the shape where it seems to work on FC5
ppc32. Now the interesting part will be to find out what exactly I did,
and do it again, without resorting to /*HACK*/ notes littered across the
code. Also there are few weird issues that remain to be resolved, such
as why is insert_breakpoint sometimes called with NULL libsym.

What was the problem:
 * secure PLT contains addresses, not instructions.  Placing breakpoint
instruction to place that would be eventually be interpreted as address
can't work.

Basically what I did:
 * secure PLT branch (now trunk) contains code to cope with secure PLTs,
with few issues to fix
 * call breakpoints_init only when the traced binary was started, you
can't ptrace it earlier
 * make sure you won't place breakpoint over another breakpoint,
otherwise you end up with breakpoint insn in orig_value, and the binary
will stuck on the first breakpoint, reinserting in endlessly.

Any advice on how to do this cleanly is welcome.

PM



More information about the Ltrace-devel mailing list