Re: What should be used instead of deprecated_read_memory_nobpt()?

[Paul Gilliam <pgilliam at us dot ibm dot com>]

Way Cool.

Thanks for the background.   Maybe someone can pick up the tourch for this.

I wonder how this fits in with Michael Snyder's multi-process gdb?
http://sourceware.org/ml/gdb-patches/2005-11/msg00490.html

-=# Paul #=-


On Tuesday 29 November 2005 17:36, Jim Blandy wrote:
> Some background:
> 
> The long-term plan here was to have GDB pass frame objects around
> everywhere, and always fetch registers and memory relative to a
> specific frame.  It's pretty obvious why you need to have a frame to
> find a register value, but why you'd want to read memory "from a
> frame" is less so.
> 
> The idea was to use frames to reduce GDB's dependence on global state:
> - A frame has a specific architecture.
> - A frame belongs to a specific thread.
> - Since threads belong to specific processes, a frame belongs to a
> specific process, too, which would help with debugging multi-address
> space programs.
> 
> So if you have a frame around to provide context for whatever you're
> trying to do, you don't have to depend on a global arch object, a
> global current thread, a global process, and so on.
> 
> This was Andrew Cagney's initiative, but he's not active on GDB any
> more, which is why I say "the idea was to..."  I think it's a good
> approach, as far as it goes, and I hope we carry it on.  We should use
> the frame-based register and memory operations whenever possible;
> where you don't have a frame, try to figure out how to propage an
> appropriate frame out to where it's needed; go ahead and add 'frame'
> parameters to functions where it makes sense.
> 
> There are some cases where it doesn't make sense.  For example, our
> 'struct value' objects read memory lazily, so if you were going to use
> frames for everything, you'd need to have the value point to the frame
> GDB should use to read the value's contents when they're actually
> needed.  But values persist across continues and steps, whereas frame
> objects are destroyed and rebuilt each time the inferior runs.  So
> values can't just point to frames.  Frame ID's are more persistent,
> but they're still not right, because the frame might really be popped
> in the inferior.
> 
> I think this shows that, to really acheive the dream, we also need an
> object representing an address space.  Memory reads and writes would
> accept an address space argument.  A thread would have a (current?)
> address space, and thus a "frame's address space" would be the
> "frame's thread's address space".  values would contain an address
> space to use to fetch their values when needed.
> 
>