This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] breakpoints and function prologues...
- From: Jim Ingham <jingham at apple dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 25 Aug 2002 15:19:44 -0700
- Subject: Re: [RFC] breakpoints and function prologues...
On Sunday, August 25, 2002, at 07:33 AM, Andrew Cagney wrote:
Yes, we could change -break-insert to do this.
It would still break when somebody uses the console to set
breakpoints from within Project Builder, however. Like with Insight,
we try to support the console as well as we can from PB (we don't do
as good a job as Insight, but we are working towards it).
We're talking Mac here right? I thought (sarcasm) Mac users did
everything using the GUI and AppleScript.
Sadly enough, half of our users are of the "If it ain't in the GUI, I
won't use it!" camp, and the other half - from the NeXT side or that
odd Unix developer or two who actually like GUI's - insist on using all
the command line features as well. Those folks are why we actually had
to get all the mi-console stuff Keith is so kindly incorporating for
eclipse working... Anyway, we don't get off easy on either score.
I am not quite sure what the point was here, however...
I guess we could go note the breakpoint set event, delete the
breakpoint that was just set IF it was set with file:line, and reset
it with the "move me past the prologue" cookie. But this seems a bit
of a hack.
Is your [apple] bug with a GUI user finding that a breakpoint on a
function confuses the GUI; or with a GUI user finding that entering
the CLI command ``break file.c:10'' confuses the GUI? (A CLI user
would have used ``break func'' :-)
The latter.
We've concluded that the former can be fixed without any need to
change the CLI.
Why would this be a problem at all? You get a breakpoint message from
the MI, and so long as the GUI knows how to take apart the location
information you are good to go. It took a little bit of work to get
typing "continue" in the console not to confuse the GUI, and even a
bit more to get things like breakpoints commands that continue the
inferior to work properly. But just noticing a breakpoint hit is dead
easy.
For the latter, the user can still enter ``break *0x1234'' and confuse
the GUI. Should GDB ``helpfully'' move that as well? I think the
only thing that can be done is ensure that the GUI doesn't get
confused (or at least gets confused gracefully :-). For instance,
realise that its got a PC in the prologue and display ``incomplete
stack frame''.
You are joking about moving an explicit address breakpoint, right?
Cause I am slightly serious about the original point. OTOH, I am not
that serious - the patch is tiny, and one I don't at all mind keeping
as a diff in our sources.
And yup, breaking on an address will confuse things too. Fortunately,
none of our users have done this, or the ones that did have been savvy
enough to cope with the side-effects of their actions.
Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
jingham@apple.com
Developer Tools - gdb