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

[Jim Blandy <jimb@red-bean.com>]

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.