This is the mail archive of the
mailing list for the GDB project.
Re: RFA: Elaborate on new overlay support
> From: Jim Blandy <firstname.lastname@example.org>
>> 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 copies *0xdead to *0xbeef
GDB knows (via the overlay table) that there is a breakpoint at both FOO
and BAR. Removing the breakpoint at foo is easy:
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?),
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.