[Ltrace-devel] 3 patches for ltrace - fixes "armhf" target

[Greg Alexander]

Hi Petr -

Thanks!  That "get_next_pcs" idiom is exactly the direction I was heading
in, and it looks like you've done a much more thorough job than I would
have.

The pmachata/arm branch works perfectly for me, and even fixes a bug that
I had on my todo-list but had not characterized yet.  I'm squared away.
Sorry I do not know how to assist getting any of these changes into
Debian's release cycle...

- Greg

On Wed, Mar 06, 2013 at 07:48:26PM +0100, Petr Machata wrote:
> Greg Alexander <ltracedeb at galexander.org> writes:
> 
> > Thanks, I got the git tree now.  I am surprised how far ahead of
> > debian-unstable it is.
> 
> You might want to consider rebasing to 0.7.2 in Debian.  That is fairly
> stable version in my opinion, which finally supports threads, fully
> understands parameter passing convention, and allows tracing not only
> the main binary, but libraries as well.  It doesn't however support ARM.
> See below for that.
> 
> > The build problem and syscall tracing have both already been fixed. :)
> 
> Great, glad to hear that.
> 
> > The PTRACE_SINGLESTEP issue remains:
> >   26753 couldn't continue when handling __libc_start_main (0x9e88) at 0x9e88
> 
> Please take a look at the branch pmachata/arm.  We actually have a full
> instruction decoding logic for software singlestepping now, ported from
> GDB.
> 
> Your idea of trying PTRACE_SINGLESTEP first is appealing.  Some ARM
> devices reportedly are capable of hardware singlestepping, but I don't
> know if the Linux kernel supports that at all, and if yes, whether
> there's a way to detect that you run on such hardware.  Unfortunately we
> can't simply try PTRACE_SINGLESTEP, as older kernels did their own
> emulation, which was unreliable, and we want to avoid using that.
> 
> Thanks,
> PM
>