Re: [RFC] breakpoints and function prologues...

[Jim Ingham <jingham@apple.com>]

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