Re: fstep added

[Mark Wielaard <mark@klomp.org>]

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