Re: fstep added

[Andrew Cagney <cagney at redhat dot com>]

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
>
>