Re: Save the length of inserted breakpoints

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 17, 2006 at 10:24:06PM +0200, Mark Kettenis wrote:
> Hmm, if I understand things correctly, the only reason why you need
> placed_size, is because we want shadow_len to tell is whether we've
> actually saved the contents or not.  This is eh, a wee bit ugly.

Correct (on both counts).

> Actually I think the z0 packet should not include the length of the
> breakpoint.  The remote stub will have to keep track of the length of
> the inserted breakpoint anyway, exactly because it has get the the
> target memory correct.

Yes... and no.  Two problems with that, which I'm sure you can see. One
is that, in practice, it's there; we can't remove it (protocol
incompatibilities), and because it's there, stub developers probably
use it.  They may have to stash this information somewhere else, but
not use that copy when actually removing the breakpoint.  Ugh!

[Actually I bet a lot of stubs DON'T get the underlying memory correct,
which makes their dependence on this even clearer.  I bet a lot of
stubs would report the breakpoint.  Most of the time, we read memory
with breakpoints removed, so a lot of stub authors may just not have
noticed this issue - and there's nothing about it in the manual.  It
might be more pragmatic to always issue the read, but I'm reluctant
unless we find real problems with it; why double the number of packets
needlessly?]

And secondly, software breakpoints seem to be such a simple concept...
but the variety of ways people find to implement them is astounding.
For instance, you would not need to record the length if you could
"shadow" executing ROM pages using RAM; you could perform memory reads
from the ROM page, and insert breakpoints onto the RAM page.

> I'm still thinking about a more elegant solution.  One would be to
> allocate the shadow contents dynamically and make it a NULL pointer if
> GDB didn't actually save any shadow contents.  Meanwhile, I spropose
> you check this in.  This issue has been on the table long enough now.

Thanks for your understanding.  If you find a nicer way, I'll pitch in
to help clean up the result.  In the mean time, we'll go with this
version.

I'm going to wait a little longer - I'd appreciate Eli's look over the
gdbint.texi bits, and I'm out of my GDB work environment at the moment
so I can't test it.

> P.S. Someone should really get rid of tm-sh.h and
> DEPRECATED_{BIG|LITTLE}_BREAKPOINT.

That's not all that someone should get rid of...

-- 
Daniel Jacobowitz
CodeSourcery