Re: [RFC] problem fetching inferior memory due to breakpoint

["Jim Blandy" <jimb at red-bean dot com>]

On 4/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> Try safe_frame_unwind_memory, the other caller of
> deprecated_read_memory_nobpt.  Many other prologue analyzers already
> seem to use that.

Prologue analyzers get called in two contexts, though: from the
skip_prologue gdbarch method, and from the frame unwinding stuff.  In
the former case, there's no frame at hand to use; there may not even
be a program running, if the user is setting breakpoints before doing
a 'run'.  I'm happy to pass a frame to my analyzer, use
safe_frame_unwind_memory when it's non-null, and target_read_memory
when it's null, but this seems klunky.

The whole reason safe_frame_unwind_memory takes a frame argument at
all is that, in the future (at present it ignores its frame argument)
the frame will identify which process/address space to read.  But
using frames for this isn't good enough, because, as skip_prologue
shows, we also need to be able to read memory when there are no frames
present.

Some of this was discussed here:
http://sourceware.org/ml/gdb/2005-11/msg00628.html

Ideally, the arch's skip_prologue function would take, in addition to
a CORE_ADDR, one of my imaginary address space objects.  Or, CORE_ADDR
would become a struct carrying an address space object and an offset
within that address space.  Then the CORE_ADDR alone would be enough
to do the read.  You could have address space objects representing the
memory loaded by a shared library, or sections of a relocatable
object, as well as live processes' address spaces.

If GDB were written in C++, we could overload +, -, etc. on CORE_ADDR
and write trim source for bloated object code... but my floor time is
up, and I defer to my esteemed (and more practical-minded) colleagues.