Re: RFA: Elaborate on new overlay support

[Andrew Cagney <ac131313@cygnus.com>]

> From: Jim Blandy <jimb@zwingli.cygnus.com>
>> Date: 09 Feb 2002 11:17:46 -0500
>> 
>> Are you sure this is the right thing?  How breakpoints are implemented
>> is usually completely hidden from the user.
> 
> 
> Not completely: we have the "hbreak" command, for example.
> 
> If you meant to tell that even "break" sometimes sets a hardware
> breakpoint, then I agree that it's an internal GDB matter, but if
> those are the cases you refer to here, there's no need to explain at
> length what hardware breakpoints are, just make a cross-reference to
> the "Breakpoints" node, where the detailed explanation should live.


Er, yes.  I think there is something more basic going on here.

The hbreak VS break command question comes up irregularly.  Should 
``break'' be allowed to set hardware breakpoints?  My memory of the 
rationale for separate break and hbreak commands is that the hardware 
breakpoint is (at least traditionally) very scarce.  Consequently the 
user is given complete and explicit control over them.  This allowing 
the user to carefully allocate those valueable resources to things like 
a breakpoint on that ROM.

Software breakpoints on the other hand were cheap. They do come with 
certain implied semantics.  They work by modifying memory in the target 
and hence move around when the target moves their memory around.  If 
this isn't happening then I would argue it isn't a software breakpoint.

I get the feeling that there are two issues lurking here:

--

Firstly there looks to be a bug in the software-breakpoint packet.

Consider the sequence:
	set software breakpoint at 0xdead
	program resumes
	program copies *0xdead to *0xbeef
	program stops
GDB knows (via the overlay table) that there is a breakpoint at both FOO 
and BAR.  Removing the breakpoint at foo is easy:
	z0,dead,4
Removing the breakpoint at ``beef'' though is impossible.  GDB knows 
what memory should be at that location.  The target doesn't - the target 
can't track where the breakpoint is (that is unless the target also 
starts tracking overlays).

I guess this suggests that when a software breakpoint is set, it returns 
the original memory value, and when cleared, that original memory value 
is included in the packet.  I remember this being suggested at the time 
(I think so that the target didn't need to record the replaced memory?), 
sigh.

--

Secondly it looks like there is a broken target.  As noted above, a 
software breakpoint has certain implied semantics (it works by modifying 
target memory).  A target implementing software breakpoints using a 
hardware breakpoint mechanisms, I think, is broken - it has broken the 
contract it made with GDB.

Presumably such a target has an infinite (or nearly so) number of 
hardware breakpoints and so doesn't see any point in using 
software-breakpoints.  While OK, this decision needs to be communicated 
back to GDB so that GDB knows what is really going on.  The old ``never 
lie'' rule applies.

enjoy,
Andrew