fstep added

fstep added

[Mark Wielaard]

Hi,

I finally added my little fstep program. It is certainly not complete,
and I am not sure it is a much use as is now since it makes programs
really, really slow. But it is a nice start for the future. You can use
it as follows:

$ frysk/bindir/fstep -i 5 -s 15000 /bin/echo

Which means, execute /bin/echo, print 5 instructions, every 15000 steps.
And gives the following output:

[30788] 0x3375dff160    add    $0x18,%rcx
[30788] 0x3375dff164    cmp    %rcx,%rsi
[30788] 0x3375dff167    jbe    0x3375dff1d8
[30788] 0x3375dff169    movzbl 0x4(%rcx),%edx
[30788] 0x3375dff16d    mov    %edx,%eax
[30788] 0x3375dff17e    cmp    $0x6,%eax
[30788] 0x3375dff181    je     0x3375dff160
[30788] 0x3375dff183    movzwl 0x6(%rcx),%edx
[30788] 0x3375dff187    test   %dx,%dx
[30788] 0x3375dff18a    jne    0x3375dff193
[30788] 0x3375dff169    movzbl 0x4(%rcx),%edx
[30788] 0x3375dff16d    mov    %edx,%eax
[30788] 0x3375dff16f    shr    $0x4,%al
[30788] 0x3375dff172    sub    $0x1,%eax
[30788] 0x3375dff175    cmp    $0x1,%al
[30788] 0x3375d271d5    add    0xfffffffffffffee8(%rbp),%rax
[30788] 0x3375d271dc    add    $0x1,%edi
[30788] 0x3375d271df    shl    $0x4,%rdx
[30788] 0x3375d271e3    mov    %esi,%esi
[30788] 0x3375d271e5    cmp    $0xc,%edi
[30788] 0x3375d73f8b    sub    $0x1,%rdx
[30788] 0x3375d73f8f    je     0x3375d73f20
[30788] 0x3375d73f91    movzbl 0x1(%r8,%rdi,1),%eax
[30788] 0x3375d73f97    movzbl 0x1(%r8,%rsi,1),%ecx
[30788] 0x3375d73f9d    add    $0x1,%r8

Total steps [30788]: 86545

You can also attach it to a running process with --pid.

The following things can/should be improved:

- It is currently build right on top of the Instruction TaskObserver. It
might be better to build it on top of the new rt framework. The rt
framework can probably also handle stepping over locking sequences like
on ppc (lwarx/stwcx).

- It only steps the main task. Plumbing is in place to track other
Tasks, but nothing is connected to that yet.

- Maybe merge it completely with ftrace?

- It is partially so slow because it accesses the Task memory for every
disassambly. Maybe that can be cached? Although instruction stepping is
just slow in general. An alternative could be combining stepping with
breakpoints set on "interesting functions". Or only stepping while in
the main program map, and not in any of the shared library maps?

- It could give the name of the memory map the PC is currently in.

- It could even give the source/line-number if available.

Note that I have marked the original tracker bug as suspended.
http://sourceware.org/bugzilla/show_bug.cgi?id=3364
If any of the above is useful they should probably be raised as bugs and
depend on #3364.

Cheers,

Mark

Re: fstep added

[Andrew Cagney]

Mark Wielaard wrote:
> Hi,
>
> I finally added my little fstep program. It is certainly not complete,
> and I am not sure it is a much use as is now since it makes programs
> really, really slow. But it is a nice start for the future. You can use
> it as follows:
>
>   

Thanks!

> You can also attach it to a running process with --pid.
>   

Most of the other utilities are now sharing a common option framework.  
Can you bug report the need to convert this code.


> The following things can/should be improved:
>
> - It is currently build right on top of the Instruction TaskObserver. It
> might be better to build it on top of the new rt framework. The rt
> framework can probably also handle stepping over locking sequences like
> on ppc (lwarx/stwcx).
>   

Yes, that's something unique to the PPC.  There's an existing bug for 
this under the PPC blocker list.

> - It only steps the main task. Plumbing is in place to track other
> Tasks, but nothing is connected to that yet.
>
> - Maybe merge it completely with ftrace?
>   

Combining single stepping and system call tracing on a Linux Kernel 
doesn't work :-(  Probably not a good idea, at least for now :-)


> - It is partially so slow because it accesses the Task memory for every
> disassambly. Maybe that can be cached? Although instruction stepping is
> just slow in general. An alternative could be combining stepping with
> breakpoints set on "interesting functions". Or only stepping while in
> the main program map, and not in any of the shared library maps?
>   

Yes, more efficient memory access will eventually be needed.  For 
insttance, by mmapping the inferior address space (I know there are 
kernel patches out there to do that), or performing larger transfers and 
caching under the hood.  Both involve careful thought, especially when 
it comes to invalidating caches, so for the moment, as you've done, the 
focus remains on correctness.

> - It could give the name of the memory map the PC is currently in.
>
> - It could even give the source/line-number if available.
>   

These are all good ideas.
> Note that I have marked the original tracker bug as suspended.
> http://sourceware.org/bugzilla/show_bug.cgi?id=3364
> If any of the above is useful they should probably be raised as bugs and
> depend on #3364.
>
> Cheers,
>
> Mark
>
>   

Re: fstep added

[Mark Wielaard]

On Mon, 2006-12-18 at 11:04 -0500, Andrew Cagney wrote:
> > You can also attach it to a running process with --pid.
> >   
> 
> Most of the other utilities are now sharing a common option framework.  
> Can you bug report the need to convert this code.

Filed as: http://sourceware.org/bugzilla/show_bug.cgi?id=3752

> > The following things can/should be improved:
> >
> > - It is currently build right on top of the Instruction TaskObserver. It
> > might be better to build it on top of the new rt framework. The rt
> > framework can probably also handle stepping over locking sequences like
> > on ppc (lwarx/stwcx).
> >   
> Yes, that's something unique to the PPC.  There's an existing bug for 
> this under the PPC blocker list.

I couldn't find the bug report. But I suppose this should be handled by
the rt RunState support and not directly in the proc TaskState.

> Yes, more efficient memory access will eventually be needed.  For 
> insttance, by mmapping the inferior address space (I know there are 
> kernel patches out there to do that), or performing larger transfers and 
> caching under the hood.  Both involve careful thought, especially when 
> it comes to invalidating caches, so for the moment, as you've done, the 
> focus remains on correctness.

Oh, nice idea. mmapping /proc/<pid>/mem would certainly speed things up.
I suppose you cannot write to it, but in most cases we only need to read
large amounts, not write them.

> > - It could give the name of the memory map the PC is currently in.
> >
> > - It could even give the source/line-number if available.
> >   
> 
> These are all good ideas.

I added them all as a comment to the (now suspended) fstep bug
http://sourceware.org/bugzilla/show_bug.cgi?id=3364

Cheers,

Mark

Re: fstep added

[Phil Muldoon]

Andrew Cagney wrote:
> Mark Wielaard wrote:
>
>> - It is partially so slow because it accesses the Task memory for every
>> disassambly. Maybe that can be cached? Although instruction stepping is
>> just slow in general. An alternative could be combining stepping with
>> breakpoints set on "interesting functions". Or only stepping while in
>> the main program map, and not in any of the shared library maps?
>>   
>
> Yes, more efficient memory access will eventually be needed.  For 
> insttance, by mmapping the inferior address space (I know there are 
> kernel patches out there to do that), or performing larger transfers 
> and caching under the hood.  Both involve careful thought, especially 
> when it comes to invalidating caches, so for the moment, as you've 
> done, the focus remains on correctness.

Resurrecting this thread for a little bit. Is this issue related to:

http://sourceware.org/bugzilla/show_bug.cgi?id=3727

I'm hazarding a guess this all comes down to ptrace accessing the 
inferior's memory word by word, and that optimizations made in access to 
the inferior's memory (ie by mmaping /proc/$$/memory) will benefit fcore 
as well as fstep? My knowledge here is really fuzzy.

Regards

Phil

Re: fstep added

[Mark Wielaard]

On Mon, 2007-01-22 at 07:51 -0600, Phil Muldoon wrote: 
> Resurrecting this thread for a little bit. Is this issue related to:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=3727
> 
> I'm hazarding a guess this all comes down to ptrace accessing the 
> inferior's memory word by word, and that optimizations made in access to 
> the inferior's memory (ie by mmaping /proc/$$/memory) will benefit fcore 
> as well as fstep? My knowledge here is really fuzzy.

Yes and http://sourceware.org/bugzilla/show_bug.cgi?id=3761 which are
basically the same issue. To speedup fstep and fcore) we would like to
mmap /proc/<pid>/mem for the inferior and wrap it in an inua ByteBuffer.
This doesn't provide write access, but we do reads mostly anyway. You
can imagine a ByteBuffer returned by Task.getMemory() that delegates
reads through such an mmap backed inua ByteBuffer and writes delegated
through a ptrace backed inua ByteBuffer.

Cheers,

Mark

Re: fstep added

[Andrew Cagney]

Unfortunatly current kernels don't allow mmapping of /proc/PID/maps; 
however open/pread works.

Andrew

Mark Wielaard wrote:
> On Mon, 2007-01-22 at 07:51 -0600, Phil Muldoon wrote: 
>   
>> Resurrecting this thread for a little bit. Is this issue related to:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=3727
>>
>> I'm hazarding a guess this all comes down to ptrace accessing the 
>> inferior's memory word by word, and that optimizations made in access to 
>> the inferior's memory (ie by mmaping /proc/$$/memory) will benefit fcore 
>> as well as fstep? My knowledge here is really fuzzy.
>>     
>
> Yes and http://sourceware.org/bugzilla/show_bug.cgi?id=3761 which are
> basically the same issue. To speedup fstep and fcore) we would like to
> mmap /proc/<pid>/mem for the inferior and wrap it in an inua ByteBuffer.
> This doesn't provide write access, but we do reads mostly anyway. You
> can imagine a ByteBuffer returned by Task.getMemory() that delegates
> reads through such an mmap backed inua ByteBuffer and writes delegated
> through a ptrace backed inua ByteBuffer.
>
> Cheers,
>
> Mark
>
>