[RFC] remote protocol and breakpoint shadow buffers

[Andrew Burgess <andrew.burgess@embecosm.com>]

I have a target, where, in order to create the frame id, I end up
having to take a peek at the target code memory.

This target is only accessed over the remote protocol, and makes use
of the Z0/z0 packets to insert and remove breakpoints.

Now, compute_frame_id is called from handle_signal_stop, which is
called from handle_inferior_event, which is called from
fetch_inferior_event.

The problematic thing for me is that handle_inferior_event is called
before the breakpoints are removed from the inferior, which happens
within normal_stop.

So, in my target's compute_frame_id handler, when I read target code
memory with target_read_memory the software breakpoints are still in
place, and at the moment, gdb does not store the memory being replaced
with a breakpoint in the breakpoint's shadow buffer, so the breakpoint
shadow mechanism does not save me.

I have a number of questions:

 1. In breakpoint_xfer_memory, when we find a breakpoint that overlaps
 the memory region being fetched, but that does not have a shadow
 buffer, should we not at least warn the user that they are about to
 see something they probably don't expect?  Maybe we'd need to filter
 any such warning to only apply to breakpoints that alter target
 memory.

 2. Should the Z0/z0 packet be filling in the shadow buffer?  I don't
 think there's a nice way to do this in general, as the Z0 packet
 relies on the remote end to pick, and place a software breakpoint,
 there's no way to know for sure how much memory was overwritten.
 Maybe the OK reply to a Z0 packet should include information about
 what was hidden so that the shadow buffer could be filled correctly?

 3. Trying to access target code memory as part of the
 compute_frame_id isn't that uncommon, I believe that (to pick two
 random targets) amd64, and arm both do this.  Here's the call graph
 for amd64, arm is similar:

 amd64_frame_this_id -> amd64_frame_cache
                     -> amd64_frame_cache_1
                     -> amd64_analyze_prologue
                     -> amd64_analyze_stack_align

 However, I don't think the targets amd64/arm are actually at risk in
 most cases, as they'll usually be using the DWARF unwinder, which
 should circumvent this issue, however, some code without an attached
 DWARF unwinder should hit this issue.

Does anyone have any suggestions as to the right way forward for
resolving this issue?  If seems like my choices are:

 (a) Extend Z0 to allow filling of the shadow buffer.

 (b) Have breakpoints be removed earlier in the stop process so that I
 don't have to worry about the shadow buffer at all.

 (c) Try very hard to rewrite my target to NOT access code memory in
 order to build the frame id.  Don't worry about other targets that
 are possibly also broken in the same way.

Any advice appreciated.

Thanks,
Andrew