[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