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

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

[Jim Ingham]

On Thursday, August 22, 2002, at 04:34  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

>> The question is, is there a strong reason to change a behavior
>> that has been consistent for a very long time (even if undocumented).
>> Even if the ability to debug the prologue is un-important for most
>> users, it is important to some, and those users (GCC developers,
>> for instance) may be quite accustomed to the current behavior.
>> I am, for instance...

The varobj code will fail with file:line number breakpoint setting on 
the { that starts the function.  This is, of course, not a problem for 
command-line gdb users, but varobj IS a part of gdb...  Until we have 
the CFI stuff well enough set up that, on landing at the beginning of 
the prologue, the scanner will tell us where the stack frame WILL be 
when it has been set up so we can record this properly, this will be a 
problem.


> Incidentally, it would make the new behavior more in line with the
> behavior seen when breaking by function name. If later we decide to
> change the "break funcname" to stop skipping prologues because GDB now
> has all the machinery that makes the skipping unnecessary, I would
> likewise argue that we should change back the behavior of "break
> linenum" as well.
>
>

The patch I sent you makes prologue skipping for file:line breakpoints 
hang off the same flag - "funfirstline" - that the function name ones 
use.  So if we decide to back it out, we just change the value we pass 
to decode_line_1, and you are done...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Andrew Cagney]

> 
> On Thursday, August 22, 2002, at 04:34  PM, gdb-patches-digest-help@sources.redhat.com wrote:
> 
>> The question is, is there a strong reason to change a behavior
>> that has been consistent for a very long time (even if undocumented).
>> Even if the ability to debug the prologue is un-important for most
>> users, it is important to some, and those users (GCC developers,
>> for instance) may be quite accustomed to the current behavior.
>> I am, for instance...

> 
> The varobj code will fail with file:line number breakpoint setting on the { that starts the function.  This is, of course, not a problem for command-line gdb users, but varobj IS a part of gdb...  Until we have the CFI stuff well enough set up that, on landing at the beginning of the prologue, the scanner will tell us where the stack frame WILL be when it has been set up so we can record this properly, this will be a problem.

Aren't varobj/MI and the CLI separate?  varobj/MI could easily request a 
prologue adjusted breakpoint without modifying the CLI.

enjoy,
Andrew

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

[Jim Ingham]

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).

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.

The other option is to add a "set make-old-gdb-users-unhappy-with-break 
{on,off}" command, and set that from the IDE when we start up gdb.  I'm 
not real thrilled about this either...

Jim

On Friday, August 23, 2002, at 11:31  AM, Andrew Cagney wrote:

>> On Thursday, August 22, 2002, at 04:34  PM, 
>> gdb-patches-digest-help@sources.redhat.com wrote:
>>> The question is, is there a strong reason to change a behavior
>>> that has been consistent for a very long time (even if undocumented).
>>> Even if the ability to debug the prologue is un-important for most
>>> users, it is important to some, and those users (GCC developers,
>>> for instance) may be quite accustomed to the current behavior.
>>> I am, for instance...
>
>> The varobj code will fail with file:line number breakpoint setting on 
>> the { that starts the function.  This is, of course, not a problem 
>> for command-line gdb users, but varobj IS a part of gdb...  Until we 
>> have the CFI stuff well enough set up that, on landing at the 
>> beginning of the prologue, the scanner will tell us where the stack 
>> frame WILL be when it has been set up so we can record this properly, 
>> this will be a problem.
>
> Aren't varobj/MI and the CLI separate?  varobj/MI could easily request 
> a prologue adjusted breakpoint without modifying the CLI.
>
> enjoy,
> Andrew
>
>
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

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

[Andrew Cagney]

> 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.

> 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'' :-)

We've concluded that the former can be fixed without any need to change 
the CLI.

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''.

Andrew

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

[Daniel Jacobowitz]

On Sun, Aug 25, 2002 at 10:33:18AM -0400, 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.
> 
> >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'' :-)
> 
> We've concluded that the former can be fixed without any need to change 
> the CLI.

But I still believe that the CLI command should skip prologues in the
first place, for at least as long as ``break func'' does.

And a CLI user might _not_ have used break func.  Here's a perfectly
good reason why: static functions do not have unique names (they don't
always have unique line numbers either but that's a different problem). 
Sometimes placing breakpoints by line number is the only way to get
them in the right place.  This happens in BFD all the time.

> 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''.

I agree that the GUI should not get confused.  But I'd still like to
see break line and break func work the same way.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jim Ingham]

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

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

[Michael Snyder]

Jim Ingham wrote:
> 
> On Thursday, August 22, 2002, at 04:34  PM,
> gdb-patches-digest-help@sources.redhat.com wrote:
> 
> >> The question is, is there a strong reason to change a behavior
> >> that has been consistent for a very long time (even if undocumented).
> >> Even if the ability to debug the prologue is un-important for most
> >> users, it is important to some, and those users (GCC developers,
> >> for instance) may be quite accustomed to the current behavior.
> >> I am, for instance...
> 
> The varobj code will fail with file:line number breakpoint setting on
> the { that starts the function.  This is, of course, not a problem for
> command-line gdb users, but varobj IS a part of gdb...  Until we have
> the CFI stuff well enough set up that, on landing at the beginning of
> the prologue, the scanner will tell us where the stack frame WILL be
> when it has been set up so we can record this properly, this will be a
> problem.

Mmmm, sorry, but writing a new bit that conflicts with an old bit
doesn't necessarily make the old bit wrong.  There's usually another
way to implement the new bit.


> > Incidentally, it would make the new behavior more in line with the
> > behavior seen when breaking by function name. If later we decide to
> > change the "break funcname" to stop skipping prologues because GDB now
> > has all the machinery that makes the skipping unnecessary, I would
> > likewise argue that we should change back the behavior of "break
> > linenum" as well.
> >
> 
> The patch I sent you makes prologue skipping for file:line breakpoints
> hang off the same flag - "funfirstline" - that the function name ones
> use.  So if we decide to back it out, we just change the value we pass
> to decode_line_1, and you are done...

But I'm not convinced that the file:line behavior was meant to
behave the same as the func_name behavior.  To me, associating 
the prologue code with the open curly brace seems natural.
You have to associate it with SOME line (or else make an even
more special case out of it).  Haveing a way to specify it by
line seems better than not having a way.  Likewise, it seems 
practical to me that the epilogue code is associated with the
close-curly brace.  That way there is a place to set a breakpoint
after the function is finished but before it returns.

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

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 11:34:14AM -0700, Michael Snyder wrote:
> But I'm not convinced that the file:line behavior was meant to
> behave the same as the func_name behavior.  To me, associating 
> the prologue code with the open curly brace seems natural.
> You have to associate it with SOME line (or else make an even
> more special case out of it).  Haveing a way to specify it by
> line seems better than not having a way.  Likewise, it seems 
> practical to me that the epilogue code is associated with the
> close-curly brace.  That way there is a place to set a breakpoint
> after the function is finished but before it returns.

(Let's not go into "meant"; it doesn't matter what it was meant to do,
just what we want it to do, I think.  In this case.)

Here's another question.  Suppose we have that bane of line-based
debugging: a function all on one line.  Should clicking on that line
breakpoint you before the prologue or after?  I say, after.

GCC will emit a line marker for the prologue, and then a (same) line
marker for the function; I'd say we should prefer the second.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jim Ingham]

On Thursday, August 15, 2002, at 02:19  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

> From: Andrew Cagney <ac131313@ges.redhat.com>
> Date: Wed Aug 14, 2002  10:57:13  PM US/Pacific
> To: gdb-patches@sources.redhat.com
> Subject: Re: [RFC] breakpoints and function prologues...
>
>
>> I agree with Jim here.  I think most folks are actually surprised to 
>> find that if they break on the "{" beginning a function (or indeed 
>> anywhere before the first executable line of code) then their 
>> backtrace will not be correct.  Understanding why this is so requires 
>> you to "pay attention to the man behind the curtain", and that we 
>> breaks the illusion that source code maps straight-forwardly onto the 
>> running program.  Where this extra knowledge is helpful (like when 
>> debugging optimized code) it is fine to require folks to have it.  
>> But here, where it really doesn't do any good, I think it is just 
>> confusing.  And, of course, it causes big heartburn for GUIs the 
>> varobj code, as I said earlier.
>> I doubt that "{" breaks on the prologue is a crucial feature of gdb, 
>> and given that there are other ways to do this, I don't think it is 
>> really worth supporting...
>
> Michael is right here.  If a CLI user sets a breakpoint on a line 
> (with code) then that user clearly wants the breakpoint set on that 
> line.

Most users I have talked to think that setting a break on the "{" at 
the beginning of a function means the same thing as setting a 
breakpoint on the function.  But that is not the case.   "break 
funcName" is AFTER the prologue, "break file:<line containing "{"> is 
the true function beginning.

Actually a better representation of the truth is "All the users I have 
talked to have cussed me out when they found out that these two were 
not equivalent".

>
> If an architecture can't unwind the frame for that breakpoint address 
> then that is a bug in the architecture and/or GDB.  The main reason 
> the average prologue analyzer doesn't handle breakpoints in the 
> prologue is, I think, more a factor of not being tested then of being 
> ``hard''.
>

There is another problem that this causes which is again fixable, but 
harder than getting backtraces right, which I mentioned in a previous 
note, but is worth repeating.

The varobj system, which is by far the best way to store variables in 
gdb for use in an IDE, needs to know the frame in which it is creating 
a varobj, when one is made.  That is so you can have varobj's for 
various stack levels at the same time, and when you go to update them, 
they will update themselves in the correct context.  You don't want 
this to be dependant on frame number since we start numbering at the 
top of the stack so the same stack frame changes its number over time, 
but it is very useful to have the varobj's persist till the frame 
actually goes out of scope.

The way the IDE's I have worked on use varobj's is that the user puts a 
breakpoint somewhere.  The IDE stops there, and creates varobj's for 
each of the local variables, so it can populate its local variables 
window.  Then each time the user steps, the IDE just tells gdb to 
update the varobj's it has lying around.

However, suppose the user puts his breakpoint on the "{" beginning a 
function (this is what most folks do when they want to break on a 
function generically, BTW.)  Then when the IDE stops, it creates the 
varobjs for the local variables, which naively get their frame context 
from the frame pointer (which because we stopped at the beginning of 
the prologue hasn't been updated yet).  Then the user steps, and all of 
the variables fail to evaluate correctly, since their frame pointer 
actually points to the previous frame, and there is no such variable in 
the previous frame...

You could imagine ways to work around this - notice you are in the 
prologue when you go to make varobj's and either try to disassemble the 
prologue to figure out what you should do to the frame pointer to make 
it right (which is not necessarily trivial), or suspend making the 
varobj's for real till you happen to end up out of the prologue (though 
then you have to explain to the user why when they first stopped in the 
function all their local variables have no values...).  Or note the 
error when it occurs and just blindly remake all the varobj's.

None of these is very satisfactory...

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Andrew Cagney]

> 
> Most users I have talked to think that setting a break on the "{" at the beginning of a function means the same thing as setting a breakpoint on the function.  But that is not the case.   "break funcName" is AFTER the prologue, "break file:<line containing "{"> is the true function beginning. 

Don't forget that ``break func'' is is going to change.  It's going to 
go back to the start of the function!

> However, suppose the user puts his breakpoint on the "{" beginning a function (this is what most folks do when they want to break on a function generically, BTW.)  Then when the IDE stops, it creates the varobjs for the local variables, which naively get their frame context from the frame pointer (which because we stopped at the beginning of the prologue hasn't been updated yet).  Then the user steps, and all of the variables fail to evaluate correctly, since their frame pointer actually points to the previous frame, and there is no such variable in the previous frame...

That is a bug in gdb.  GDB should be using the debug info that lets it 
set a breakpoint anywhere in the function.

enjoy,
Andrew

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

[Joel Brobecker]

> Don't forget that ``break func'' is is going to change.  It's going to 
> go back to the start of the function!

Why this change? This is going to have a negative effect on the 
Alpha Tru64 platform, since the first 2 instructions of the prologue
are often optimized out by the linker. If we move "break func" back to
the start of the function, the breakpoint will never be hit even if the
function is entered.

I agree with Daniel and Jim here: most of our users don't know what a
function prologue is. To take one example, they don't understand why the
parameter values are not correct when they put a breakpoint on the curly
brace. There is no definite answer whether we should skip the prologue
or not, but I believe that GDB users debugging at the source level will
much more often want GDB to be "prologue-transparent". For those of us
who sometimes debug at the instruction level, there are other
alternatives that allow us to do what we want.

-- 
Joel

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

[Jim Blandy]

Joel Brobecker <brobecker@gnat.com> writes:
> > Don't forget that ``break func'' is is going to change.  It's going to 
> > go back to the start of the function!
> 
> Why this change? This is going to have a negative effect on the 
> Alpha Tru64 platform, since the first 2 instructions of the prologue
> are often optimized out by the linker. If we move "break func" back to
> the start of the function, the breakpoint will never be hit even if the
> function is entered.

If I understand the optimization you're referring to, GDB's prologue
policy accomodates that behavior almost by accident.  It's basically
an entirely separate reason to skip prologues, and I'm not sure it's
germane to the broader debate here.

Let me make sure I understand what the Tru64 linker is doing.  It
recognizes that the first two instructions at some function's entry
point are unnecessary, and then it ... here is where I get vague.
Does it:
a) delete those two instructions from the code stream altogether,
   shifting all subsequent instructions down in memory,
b) leave the instructions there, but adjust the value of the linker
   symbol to point two instructions beyond where it used to, or
c) leave the instructions and the linker symbol value unchanged, but
   tweak certain jumps to that symbol to actually jump two
   instructions beyond the symbol's value?

I assume it's not a), since you wouldn't have a problem in that case.

I kind of think that b) and c) are not entirely GDB's problem: after
performing that optimization, then the entry point in the debug
information is incorrect.  Requiring GDB to skip prologues just to
accomodate this optimization is not the right design.

Prologue skipping is meant to allow GDB to stop the inferior after the
frame pointer has been updated, the return address has been saved, and
register arguments have been spilled to their stack slots.  It exists
to support a simplistic assumption elsewhere in GDB: that saved frame
pointers, return addresses, and variables live in a single place
throughout the function's lifetime.  Removing that assumption (e.g.,
by supporting CFI and location lists) makes prologue analysis
unnecessary.

But what you're describing here is a rather different situation: the
function has multiple entry points, depending on whether (I'm
guessing) it's reached via an intra- or inter-load module call.

It seems to me there should be a separate gdbarch method to handle
that, because its semantics are different.

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

[Joel Brobecker]

> Let me make sure I understand what the Tru64 linker is doing.  It
> recognizes that the first two instructions at some function's entry
> point are unnecessary, and then it ... here is where I get vague.
> Does it:
> a) delete those two instructions from the code stream altogether,
>    shifting all subsequent instructions down in memory,
> b) leave the instructions there, but adjust the value of the linker
>    symbol to point two instructions beyond where it used to, or
> c) leave the instructions and the linker symbol value unchanged, but
>    tweak certain jumps to that symbol to actually jump two
>    instructions beyond the symbol's value?

The linker is doing c).

> But what you're describing here is a rather different situation: the
> function has multiple entry points, depending on whether (I'm
> guessing) it's reached via an intra- or inter-load module call.
> 
> It seems to me there should be a separate gdbarch method to handle
> that, because its semantics are different.

Fair enough. I like this design.

-- 
Joel

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

[Daniel Jacobowitz]

On Thu, Aug 15, 2002 at 09:05:15PM -0400, Andrew Cagney wrote:
> >
> >Most users I have talked to think that setting a break on the "{" at the 
> >beginning of a function means the same thing as setting a breakpoint on 
> >the function.  But that is not the case.   "break funcName" is AFTER the 
> >prologue, "break file:<line containing "{"> is the true function 
> >beginning. 
> 
> Don't forget that ``break func'' is is going to change.  It's going to 
> go back to the start of the function!
> 
> >However, suppose the user puts his breakpoint on the "{" beginning a 
> >function (this is what most folks do when they want to break on a function 
> >generically, BTW.)  Then when the IDE stops, it creates the varobjs for 
> >the local variables, which naively get their frame context from the frame 
> >pointer (which because we stopped at the beginning of the prologue hasn't 
> >been updated yet).  Then the user steps, and all of the variables fail to 
> >evaluate correctly, since their frame pointer actually points to the 
> >previous frame, and there is no such variable in the previous frame...
> 
> That is a bug in gdb.  GDB should be using the debug info that lets it 
> set a breakpoint anywhere in the function.

If you are suggesting that someday we'll support accessing local
variables using better unwind information and prologue analysis -
including for targets where no one has written a better prologue
analyzer yet and for debug formats which don't emit terribly good
unwind information, which covers most of our targets twice over - then
I have to say that ``break func'' _shouldn't_ change.

It'd be nice, but I don't think it's realistic.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > Most users I have talked to think that setting a break on the "{" at
> > the beginning of a function means the same thing as setting a
> > breakpoint on the function.  But that is not the case.   "break
> > funcName" is AFTER the prologue, "break file:<line containing "{">
> > is the true function beginning.
> 
> Don't forget that ``break func'' is is going to change.  It's going to
> go back to the start of the function!

... but only once GDB uses CFI and location lists to make prologue
identification irrelevant.  At that point, we've all agreed, this
debate doesn't matter any more.  The issue is what to do until then.

Or are you saying that they should simply wait until that work is
complete?  When do we expect it to be complete?

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

[Jim Ingham]

Not to do a pile-on here, but I agree with the other folks.

First off - what benefits do we get from moving "break func" to the 
beginning of the prologue that should make us in a hurry to do it 
before all or at least most of the targets & debug formats support it 
well?  People who actually want to see the prologue are probably savvy 
enough to figure out how to do that (it isn't that hard).  Most folks, 
however, could care less about it.  The majority of the responses we 
got when I explained the varobj bug on the Project Builder Users list 
were along the lines of "What is a prologue, and why should I care 
about it".  The most satisfactory answer for most of them was "You 
really shouldn't care"...

And as a sorry stabs user, I don't see good unwind info coming down the 
pike any time soon.  Sure, I would love to get our toolchain to emit 
Dwarf, but there is a lot of work to get there (among other things, 
until duplicate header information elimination is done no one here is 
going to pay any attention to Dwarf).  In the meantime, we have 
unacceptable behavior from gdb with no easy way to fix it other than 
the solution proposed - move the break for line numbers past the 
prologue.

Jim

On Thursday, August 15, 2002, at 06:05  PM, Andrew Cagney wrote:

>> Most users I have talked to think that setting a break on the "{" at 
>> the beginning of a function means the same thing as setting a 
>> breakpoint on the function.  But that is not the case.   "break 
>> funcName" is AFTER the prologue, "break file:<line containing "{"> is 
>> the true function beginning.
>
> Don't forget that ``break func'' is is going to change.  It's going to 
> go back to the start of the function!
>
>> However, suppose the user puts his breakpoint on the "{" beginning a 
>> function (this is what most folks do when they want to break on a 
>> function generically, BTW.)  Then when the IDE stops, it creates the 
>> varobjs for the local variables, which naively get their frame 
>> context from the frame pointer (which because we stopped at the 
>> beginning of the prologue hasn't been updated yet).  Then the user 
>> steps, and all of the variables fail to evaluate correctly, since 
>> their frame pointer actually points to the previous frame, and there 
>> is no such variable in the previous frame...
>
> That is a bug in gdb.  GDB should be using the debug info that lets it 
> set a breakpoint anywhere in the function.
>
> enjoy,
> Andrew
>
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Michael Snyder]

Andrew Cagney wrote:
> 
> >
> > Most users I have talked to think that setting a break on the "{" at the beginning of a function means the same thing as setting a breakpoint on the function.  But that is not the case.   "break funcName" is AFTER the prologue, "break file:<line containing "{"> is the true function beginning.
> 
> Don't forget that ``break func'' is is going to change.  It's going to
> go back to the start of the function!

???
Since when?

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

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> 
> 
>> >
>> > Most users I have talked to think that setting a break on the "{" at the beginning of a function means the same thing as setting a breakpoint on the function.  But that is not the case.   "break funcName" is AFTER the prologue, "break file:<line containing "{"> is the true function beginning.
> 
>> 
>> Don't forget that ``break func'' is is going to change.  It's going to
>> go back to the start of the function!
> 
> 
> ???
> Since when?

When an architecture enables CFI.  CFI removes any technical reason for 
skipping the prologue (what break foo does'') -- CFI allows you to find 
the value of registers and variables at any point in the code.

Of course,we could always leave ``break foo''.

Andrew

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

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Andrew Cagney wrote:
> >
> >>
> >
> >> >
> >> > Most users I have talked to think that setting a break on the "{" at the beginning of a function means the same thing as setting a breakpoint on the function.  But that is not the case.   "break funcName" is AFTER the prologue, "break file:<line containing "{"> is the true function beginning.
> >
> >>
> >> Don't forget that ``break func'' is is going to change.  It's going to
> >> go back to the start of the function!
> >
> >
> > ???
> > Since when?
> 
> When an architecture enables CFI.  CFI removes any technical reason for
> skipping the prologue (what break foo does'') -- CFI allows you to find
> the value of registers and variables at any point in the code.
> 
> Of course,we could always leave ``break foo''.

You mean leave SKIP_PROLOGUE on ``break foo'', right?
Frankly, I see no reason to change it.

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

[Jim Ingham]

I agree with Jim here.  I think most folks are actually surprised to 
find that if they break on the "{" beginning a function (or indeed 
anywhere before the first executable line of code) then their backtrace 
will not be correct.  Understanding why this is so requires you to "pay 
attention to the man behind the curtain", and that we breaks the 
illusion that source code maps straight-forwardly onto the running 
program.  Where this extra knowledge is helpful (like when debugging 
optimized code) it is fine to require folks to have it.  But here, 
where it really doesn't do any good, I think it is just confusing.  
And, of course, it causes big heartburn for GUIs the varobj code, as I 
said earlier.

I doubt that "{" breaks on the prologue is a crucial feature of gdb, 
and given that there are other ways to do this, I don't think it is 
really worth supporting...

Jim


On Saturday, August 3, 2002, at 10:32  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

> From: Jim Blandy <jimb@redhat.com>
> Date: Fri Aug 2, 2002  11:48:26  PM US/Pacific
> To: Michael Snyder <msnyder@redhat.com>
> Cc: Joel Brobecker <brobecker@gnat.com>, gdb-patches@sources.redhat.com
> Subject: Re: [RFC] breakpoints and function prologues...
>
>
>
> Michael Snyder <msnyder@redhat.com> writes:
>>> So I'd support changing `break LINENO' to always skip the prologue.
>>
>> I would not.  It's changing a behavior that people have
>> become accustomed to.
>
> Well, that alone isn't a good reason to keep a behavior, is it?  I
> mean, it's pretty confusing.  And there's a good alternative.
>
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Andrew Cagney]

> I agree with Jim here.  I think most folks are actually surprised to find that if they break on the "{" beginning a function (or indeed anywhere before the first executable line of code) then their backtrace will not be correct.  Understanding why this is so requires you to "pay attention to the man behind the curtain", and that we breaks the illusion that source code maps straight-forwardly onto the running program.  Where this extra knowledge is helpful (like when debugging optimized code) it is fine to require folks to have it.  But here, where it really doesn't do any good, I think it is just confusing.  And, of course, it causes big heartburn for GUIs the varobj code, as I said earlier.
> 
> I doubt that "{" breaks on the prologue is a crucial feature of gdb, and given that there are other ways to do this, I don't think it is really worth supporting...

Michael is right here.  If a CLI user sets a breakpoint on a line (with 
code) then that user clearly wants the breakpoint set on that line.

If an architecture can't unwind the frame for that breakpoint address 
then that is a bug in the architecture and/or GDB.  The main reason the 
average prologue analyzer doesn't handle breakpoints in the prologue is, 
I think, more a factor of not being tested then of being ``hard''.

Andrew


> On Saturday, August 3, 2002, at 10:32  PM, gdb-patches-digest-help@sources.redhat.com wrote:
> 
> From: Jim Blandy <jimb@redhat.com>
> Date: Fri Aug 2, 2002  11:48:26  PM US/Pacific
> To: Michael Snyder <msnyder@redhat.com>
> Cc: Joel Brobecker <brobecker@gnat.com>, gdb-patches@sources.redhat.com
> Subject: Re: [RFC] breakpoints and function prologues...
> 
> 
> 
> Michael Snyder <msnyder@redhat.com> writes:
> So I'd support changing `break LINENO' to always skip the prologue.
> 
> I would not.  It's changing a behavior that people have
> become accustomed to.
> 
> Well, that alone isn't a good reason to keep a behavior, is it?  I
> mean, it's pretty confusing.  And there's a good alternative.
> 
> 
> 
> -- 
> Jim Ingham                                   jingham@apple.com
> Developer Tools - gdb
> Apple Computer
> 
> 

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

[Daniel Jacobowitz]

On Thu, Aug 15, 2002 at 01:57:13AM -0400, Andrew Cagney wrote:
> >I agree with Jim here.  I think most folks are actually surprised to find 
> >that if they break on the "{" beginning a function (or indeed anywhere 
> >before the first executable line of code) then their backtrace will not be 
> >correct.  Understanding why this is so requires you to "pay attention to 
> >the man behind the curtain", and that we breaks the illusion that source 
> >code maps straight-forwardly onto the running program.  Where this extra 
> >knowledge is helpful (like when debugging optimized code) it is fine to 
> >require folks to have it.  But here, where it really doesn't do any good, 
> >I think it is just confusing.  And, of course, it causes big heartburn for 
> >GUIs the varobj code, as I said earlier.
> >
> >I doubt that "{" breaks on the prologue is a crucial feature of gdb, and 
> >given that there are other ways to do this, I don't think it is really 
> >worth supporting...
> 
> Michael is right here.  If a CLI user sets a breakpoint on a line (with 
> code) then that user clearly wants the breakpoint set on that line.

Sure, if the user knows there's code there.  I don't think most of our
users would understand that there is code on the "{", or what it is
for - and I don't think that breaking by line number should break on
code inserted by the compiler rather than the user.

So I have to agree with Jim (both Jims, I think?).

> If an architecture can't unwind the frame for that breakpoint address 
> then that is a bug in the architecture and/or GDB.  The main reason the 
> average prologue analyzer doesn't handle breakpoints in the prologue is, 
> I think, more a factor of not being tested then of being ``hard''.

Most of our ports don't support it, however.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Aug 15, 2002 at 01:57:13AM -0400, Andrew Cagney wrote:
> > >I agree with Jim here.  I think most folks are actually surprised to find
> > >that if they break on the "{" beginning a function (or indeed anywhere
> > >before the first executable line of code) then their backtrace will not be
> > >correct.  Understanding why this is so requires you to "pay attention to
> > >the man behind the curtain", and that we breaks the illusion that source
> > >code maps straight-forwardly onto the running program.  Where this extra
> > >knowledge is helpful (like when debugging optimized code) it is fine to
> > >require folks to have it.  But here, where it really doesn't do any good,
> > >I think it is just confusing.  And, of course, it causes big heartburn for
> > >GUIs the varobj code, as I said earlier.
> > >
> > >I doubt that "{" breaks on the prologue is a crucial feature of gdb, and
> > >given that there are other ways to do this, I don't think it is really
> > >worth supporting...
> >
> > Michael is right here.  If a CLI user sets a breakpoint on a line (with
> > code) then that user clearly wants the breakpoint set on that line.
> 
> Sure, if the user knows there's code there.  I don't think most of our
> users would understand that there is code on the "{", or what it is
> for -

I suspect that this is a result of a changing user base.
There are more and more users who don't know a lot about
how things work "under the hood".

> and I don't think that breaking by line number should break on
> code inserted by the compiler rather than the user.

The question is, is there a strong reason to change a behavior
that has been consistent for a very long time (even if undocumented).
Even if the ability to debug the prologue is un-important for most
users, it is important to some, and those users (GCC developers,
for instance) may be quite accustomed to the current behavior.
I am, for instance...


> So I have to agree with Jim (both Jims, I think?).
> 
> > If an architecture can't unwind the frame for that breakpoint address
> > then that is a bug in the architecture and/or GDB.  The main reason the
> > average prologue analyzer doesn't handle breakpoints in the prologue is,
> > I think, more a factor of not being tested then of being ``hard''.
> 
> Most of our ports don't support it, however.

Most of mine do.

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

[Joel Brobecker]

> The question is, is there a strong reason to change a behavior
> that has been consistent for a very long time (even if undocumented).
> Even if the ability to debug the prologue is un-important for most
> users, it is important to some, and those users (GCC developers,
> for instance) may be quite accustomed to the current behavior.
> I am, for instance...

I would not say a "strong" reason, but as you say, the user base has
shifted, and supposing that ACT's customer base is representative of the
user base, a good part of the users are surprised by the current
behavior.

Incidentally, it would make the new behavior more in line with the
behavior seen when breaking by function name. If later we decide to
change the "break funcname" to stop skipping prologues because GDB now
has all the machinery that makes the skipping unnecessary, I would
likewise argue that we should change back the behavior of "break
linenum" as well.

-- 
Joel

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

[Daniel Jacobowitz]

On Thu, Aug 22, 2002 at 03:31:52PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Aug 15, 2002 at 01:57:13AM -0400, Andrew Cagney wrote:
> > > >I agree with Jim here.  I think most folks are actually surprised to find
> > > >that if they break on the "{" beginning a function (or indeed anywhere
> > > >before the first executable line of code) then their backtrace will not be
> > > >correct.  Understanding why this is so requires you to "pay attention to
> > > >the man behind the curtain", and that we breaks the illusion that source
> > > >code maps straight-forwardly onto the running program.  Where this extra
> > > >knowledge is helpful (like when debugging optimized code) it is fine to
> > > >require folks to have it.  But here, where it really doesn't do any good,
> > > >I think it is just confusing.  And, of course, it causes big heartburn for
> > > >GUIs the varobj code, as I said earlier.
> > > >
> > > >I doubt that "{" breaks on the prologue is a crucial feature of gdb, and
> > > >given that there are other ways to do this, I don't think it is really
> > > >worth supporting...
> > >
> > > Michael is right here.  If a CLI user sets a breakpoint on a line (with
> > > code) then that user clearly wants the breakpoint set on that line.
> > 
> > Sure, if the user knows there's code there.  I don't think most of our
> > users would understand that there is code on the "{", or what it is
> > for -
> 
> I suspect that this is a result of a changing user base.
> There are more and more users who don't know a lot about
> how things work "under the hood".

Absolutely.

> > and I don't think that breaking by line number should break on
> > code inserted by the compiler rather than the user.
> 
> The question is, is there a strong reason to change a behavior
> that has been consistent for a very long time (even if undocumented).
> Even if the ability to debug the prologue is un-important for most
> users, it is important to some, and those users (GCC developers,
> for instance) may be quite accustomed to the current behavior.
> I am, for instance...

I believe there's a strong reason; the change in our user base means
that this confuses more people than it helps.  Most or all of the
people who need to look at the beginning of prologues know about "break
*foo".

> 
> 
> > So I have to agree with Jim (both Jims, I think?).
> > 
> > > If an architecture can't unwind the frame for that breakpoint address
> > > then that is a bug in the architecture and/or GDB.  The main reason the
> > > average prologue analyzer doesn't handle breakpoints in the prologue is,
> > > I think, more a factor of not being tested then of being ``hard''.
> > 
> > Most of our ports don't support it, however.
> 
> Most of mine do.

Enough to provide frame information for local variables and stack
arguments at that point?  I didn't think that was the case.  Without
using CFI or a much more sophisticated prologue analysis mechanism, I
don't see how it could be... but I could certainly be wrong :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[RFC] breakpoints and function prologues...

[Jim Ingham]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Joel,

I did the same thing for Apple's gdb, and for the same reasons you 
mentioned.  The solution for the GUI is still not perfect, because you 
end up either moving the breakpoint indicator on them, or you end up 
stopping at the breakpoint but having the PC marker not be where the 
breakpoint marker is, both of which are a little disconcerting.

Another strong reason for doing this in a GUI is if you are using 
varobj's to represent variables.  The reason for this is that the 
varobj stores the frame in which it is valid when it is made.  If you 
stop at the beginning of the function and make varobj's for all the 
local variables (which is the usual mode for a GUI) then the frame that 
is recorded will be the frame of the previous function ('cause the 
frame pointer hasn't been moved yet).  When you then step into the 
function, all the varobj's are now out of scope.  Oops...  At which 
point somebody needs to be smart enough to guess what has happened, 
trash all the varobj's and recreate them in the current scope.  Not a 
very good way to go.

I solved the problem a little differently, however.  The fact is that 
decode_line_1 takes a funfirstline argument, which is supposed to tell 
it whether to move the breakpoint past the prologue.  But it doesn't 
look at this argument in the case of setting a file:line breakpoint.  
So I just made it do that.  I like this solution, because it unifies in 
concept the breakpoint moving done for function symbols and for 
file:line symbols (though as you see, the actual motion is handled by 
different pieces of code.)

I attached that patch below.


[-- Attachment #2: linespec.c.diff --]
[-- Type: application/octet-stream, Size: 1267 bytes --]

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.18
diff -c -w -r1.18 linespec.c
*** linespec.c	5 Apr 2002 22:04:41 -0000	1.18
--- linespec.c	23 Jul 2002 01:09:59 -0000
***************
*** 1070,1076 ****
--- 1070,1100 ----
        if (val.symtab == 0)
  	val.symtab = s;
  
+       /* If funfirstline is set, we need to look up the function
+        containing the line, and move past the prologue. */
+ 
        val.pc = 0;
+       if (funfirstline)
+       {
+         CORE_ADDR pc = 0;
+ 
+         if (find_line_pc (val.symtab, val.line, &pc))
+           {
+             struct symbol *func_sym;
+             struct symtab_and_line sal;
+             
+             func_sym = find_pc_function (pc);
+             if (func_sym)
+               {
+                 sal = find_function_start_sal (func_sym, 1);
+                 /* Don't move the line, just set the pc
+                    to the right place. */
+                 if (val.line <= sal.line)
+                   val.pc = sal.pc;
+               }
+           }
+       }
+ 
        values.sals = (struct symtab_and_line *)
  	xmalloc (sizeof (struct symtab_and_line));
        values.sals[0] = val;

[-- Attachment #3: Type: text/plain, Size: 3826 bytes --]



Jim


On Monday, July 22, 2002, at 05:36  PM, 
gdb-patches-digest-help@sources.redhat.com wrote:

>
>
> I would like to have your opinion on the following issue. This is more
> spectacular on Tru64, but the idea behind this can be reproduced on any
> system.
>
> Given the following simple program:
>           1       #include <stdio.h>
>           2
>           3       void
>           4       hello (void)
>           5       {
>           6         printf ("Hello world.\n");
>           7       }
>           8
>           9       int
>           10      main (void)
>           11      {
>           12        hello ();
>           13        return 0;
>           14      }
> (compiled using "gcc -g hello.c -o hello")
>
> The program does not stop if I put a breakpoint at line 4 before 
> running it:
>
>          (gdb) b hello.c:4
>          Breakpoint 1 at 0x120001150: file hello.c, line 4.
>          (gdb) run
>          Starting program: /usr/prague.a/brobecke/skip_prologue/hello
>          Hello world.
>
>          Program exited normally.
>          (gdb)
>
> On the other hand, if I use the function name to put the breakpoint,
> then the program stops:
>
>          (gdb) b hello
>          Breakpoint 2 at 0x120001168: file hello.c, line 6.
>          (gdb) run
>          Starting program: /usr/prague.a/brobecke/skip_prologue/hello
>
>          Breakpoint 2, hello () at hello.c:6
>          6         printf ("Hello world.\n");
>          (gdb)
>
> It is more spectacular in the Tru64 case, because the Tru64 linker
> performs some optimization by default that often cause the first few
> instructions to be skipped (usually the instruction loading the gp).
> A disass in function main() shows this:
>
>          0x1200011b0 <main+24>:  bsr     ra,0x120001158 <hello+8>
>
> But the problem is a bit more general that this:
>
>   - "break function-name" causes GDB to skip the function prologue
>   - On the other hand, "break file:line_num" does not cause GDB to skip
>     the function prologue
>
> Some of our users have been confused by this, mostly because they use a
> graphical front-end where it is so easy to click to put a breakpoint on
> a given line that they sometimes don't know or want to know that there
> are other ways to insert breakpoints.
>
> Some of our users thought that breakpoint 1 and 2 above where
> equivalent, and where therefore surprised to see that their function
> parameters had junk values. Once you know that in case of breakpoint 1,
> the prologue has not been executed, it is easy to figure out that the
> parameter homing had not taken place yet, hence the incorrect values.
>
> In our experience, the only case when a user don't want to skip the
> function prologue is when doing instruction-level debugging. So, we are
> considering changing the behavior of the "break file:line-num" command
> to behave like "break function-name", that is slightly offset the
> breakpoint address to skip the prologue.
>
> That will fix the Tru64 problem, and we believe that it will make GDB
> more user-friendly by making breakpoint 1 and 2 equivalent. I would 
> like
> to have your opinion on this.
>
> Interestingly enough, I had made a prototype change that was adding 
> this
> capability to GDB due to another problem (it was a compiler deficiency
> that I wanted to work-around in GDB). I never finished this work 
> because
> I convinced myself that it was better to fix the compiler (which, due 
> to
> lack of time, I haven't done yet :-). I am attaching this patch to this
> mail just as a reference. It probably needs a bit of dusting off, and
> some touch-ups before it is suitable for submission if the GDB 
> community
> like the idea.
>
> -- 
> Joel
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

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

[Joel Brobecker]

Jim,

> I solved the problem a little differently, however.  The fact is that 
> decode_line_1 takes a funfirstline argument, which is supposed to tell 
> it whether to move the breakpoint past the prologue.  But it doesn't 
> look at this argument in the case of setting a file:line breakpoint.  
> So I just made it do that.  I like this solution, because it unifies in 
> concept the breakpoint moving done for function symbols and for 
> file:line symbols (though as you see, the actual motion is handled by 
> different pieces of code.)
> 
> I attached that patch below.

Thanks for your feedback.

I must say I really prefer your patch over mine. I hope this patch will
be approved for inclusion.

-- 
Joel

[RFC] breakpoints and function prologues...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]

I would like to have your opinion on the following issue. This is more
spectacular on Tru64, but the idea behind this can be reproduced on any
system.

Given the following simple program:
          1       #include <stdio.h>
          2
          3       void
          4       hello (void)
          5       {
          6         printf ("Hello world.\n");
          7       }
          8
          9       int
          10      main (void)
          11      {
          12        hello ();
          13        return 0;
          14      }
(compiled using "gcc -g hello.c -o hello")

The program does not stop if I put a breakpoint at line 4 before running it:

         (gdb) b hello.c:4
         Breakpoint 1 at 0x120001150: file hello.c, line 4.
         (gdb) run
         Starting program: /usr/prague.a/brobecke/skip_prologue/hello 
         Hello world.
         
         Program exited normally.
         (gdb)

On the other hand, if I use the function name to put the breakpoint,
then the program stops:

         (gdb) b hello
         Breakpoint 2 at 0x120001168: file hello.c, line 6.
         (gdb) run
         Starting program: /usr/prague.a/brobecke/skip_prologue/hello 
         
         Breakpoint 2, hello () at hello.c:6
         6         printf ("Hello world.\n");
         (gdb)

It is more spectacular in the Tru64 case, because the Tru64 linker
performs some optimization by default that often cause the first few
instructions to be skipped (usually the instruction loading the gp).
A disass in function main() shows this:

         0x1200011b0 <main+24>:  bsr     ra,0x120001158 <hello+8>

But the problem is a bit more general that this:

  - "break function-name" causes GDB to skip the function prologue
  - On the other hand, "break file:line_num" does not cause GDB to skip
    the function prologue

Some of our users have been confused by this, mostly because they use a
graphical front-end where it is so easy to click to put a breakpoint on
a given line that they sometimes don't know or want to know that there
are other ways to insert breakpoints.

Some of our users thought that breakpoint 1 and 2 above where
equivalent, and where therefore surprised to see that their function
parameters had junk values. Once you know that in case of breakpoint 1,
the prologue has not been executed, it is easy to figure out that the
parameter homing had not taken place yet, hence the incorrect values.

In our experience, the only case when a user don't want to skip the
function prologue is when doing instruction-level debugging. So, we are
considering changing the behavior of the "break file:line-num" command
to behave like "break function-name", that is slightly offset the
breakpoint address to skip the prologue.

That will fix the Tru64 problem, and we believe that it will make GDB
more user-friendly by making breakpoint 1 and 2 equivalent. I would like
to have your opinion on this.

Interestingly enough, I had made a prototype change that was adding this
capability to GDB due to another problem (it was a compiler deficiency
that I wanted to work-around in GDB). I never finished this work because
I convinced myself that it was better to fix the compiler (which, due to
lack of time, I haven't done yet :-). I am attaching this patch to this
mail just as a reference. It probably needs a bit of dusting off, and
some touch-ups before it is suitable for submission if the GDB community
like the idea.

-- 
Joel

[-- Attachment #2: bp.diff --]
[-- Type: text/plain, Size: 4230 bytes --]

Index: breakpoint.c
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-5/gdb/breakpoint.c,v
retrieving revision 1.1.1.1.2.6
diff -u -5 -r1.1.1.1.2.6 breakpoint.c
--- breakpoint.c	5 Feb 2002 08:59:32 -0000	1.1.1.1.2.6
+++ breakpoint.c	6 Feb 2002 11:22:00 -0000
@@ -4726,23 +4726,41 @@
 	    (*addr_string)[i] = savestring (addr_start, (*address) - addr_start);
 	}
     }
 }
 
-
 /* Convert each SAL into a real PC.  Verify that the PC can be
    inserted as a breakpoint.  If it can't throw an error. */
 
 void
 breakpoint_sals_to_pc (struct symtabs_and_lines *sals,
-		       char *address)
+		       char *address,
+                       char **address_string)
 {    
   int i;
   for (i = 0; i < sals->nelts; i++)
     {
       resolve_sal_pc (&sals->sals[i]);
 
+      /* If the PC for the breakpoint points to the first instruction
+         of a function (ie the begining of a function prologue), then
+         skip the prologue. What happens is that certain smart linkers
+         such as the Tru64 linker perform some optimizations which
+         sometimes cause part of the prologue to be skipped. The
+         consequence for the user is that his breakpoint is never hit
+         even though his code is actually executed.
+             
+         Do not perform this adjustment if the user asked to put the
+         breakpoint at a specified address (using the *addr notation).
+         If the user goes down to this level, it is likely that he knows
+         what he is doing. */
+
+      if (address_string[i] != NULL &&
+          address_string[i][0] != '*' &&
+          get_pc_function_start (sals->sals[i].pc) == sals->sals[i].pc)
+        sals->sals[i].pc = SKIP_PROLOGUE (sals->sals[i].pc);
+
       /* It's possible for the PC to be nonzero, but still an illegal
          value on some targets.
 
          For example, on HP-UX if you start gdb, and before running the
          inferior you try to set a breakpoint on a shared library function
@@ -4834,11 +4852,11 @@
 	make_cleanup (free, addr_string[i]);
     }
 
   /* Resolve all line numbers to PC's and verify that the addresses
      are ok for the target.  */
-  breakpoint_sals_to_pc (&sals, addr_start);
+  breakpoint_sals_to_pc (&sals, addr_start, addr_string);
 
   /* Verify that condition can be parsed, before setting any
      breakpoints.  Allocate a separate condition expression for each
      breakpoint. */
   thread = -1;			/* No specific thread yet */
@@ -4994,11 +5012,11 @@
      memory. */
   if (*address_end != '\0')
     error ("Garbage %s following breakpoint address", address_end);
 
   /* Resolve all line numbers to PC's.  */
-  breakpoint_sals_to_pc (&sals, args->address);
+  breakpoint_sals_to_pc (&sals, args->address, addr_string);
 
   /* Verify that conditions can be parsed, before setting any
      breakpoints.  */
   for (i = 0; i < sals.nelts; i++)
     {
@@ -7087,10 +7105,27 @@
       s = b->addr_string;
       sals = decode_line_1 (&s, 1, (struct symtab *) NULL, 0, (char ***) NULL);
       for (i = 0; i < sals.nelts; i++)
 	{
 	  resolve_sal_pc (&sals.sals[i]);
+
+          /* If the PC for the breakpoint points to the first instruction
+             of a function (ie the begining of a function prologue), then
+             skip the prologue. What happens is that certain smart linkers
+             such as the Tru64 linker perform some optimizations which
+             sometimes cause part of the prologue to be skipped. The
+             consequence for the user is that his breakpoint is never
+             hit even though his code is actually executed. 
+             
+             Do not perform this adjustment if the user asked to put the
+             breakpoint at a specified address (using the *addr notation).
+             If the user goes down to this level, it is likely that he knows
+             what he is doing. */
+
+          if (s[0] != '*' &&
+              get_pc_function_start (sals.sals[i].pc) == sals.sals[i].pc)
+            sals.sals[i].pc = SKIP_PROLOGUE (sals.sals[i].pc);
 
 	  /* Reparse conditions, they might contain references to the
 	     old symtab.  */
 	  if (b->cond_string != NULL)
 	    {

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

[Jim Blandy]

In the long term, if we can get GDB to use Dwarf 2 CFI and location
lists, there will be no difference between setting breakpoints before
or after the prologue.  The prologue scanning and skipping behavior
will only be necessary in the absence of that debugging info.

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

[Joel Brobecker]

> In the long term, if we can get GDB to use Dwarf 2 CFI and location
> lists, there will be no difference between setting breakpoints before
> or after the prologue.  The prologue scanning and skipping behavior
> will only be necessary in the absence of that debugging info.

I agree.

In the meantime, may I suggest we install Jim Ingham's patch? I think
the new behavior would be more useful than the current, but maybe I'm
wrong?

Another alternative that has been discussed at ACT is to move the line
where the function declaration is located to an address immediately
past the function prologue. And the prologue would get a separate line
info entry with a line number set to 0. The rationale behind modifying
the compiler is that the compiler knows much better than GDB what part
of the code is the prologue, and therefore should be in a better
position of to provide accurate line information.

But I personally (ie I'm not speaking for ACT) prefer changing GDB. What
do you think?

-- 
Joel

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

[Daniel Jacobowitz]

On Thu, Jul 25, 2002 at 10:33:20PM -0700, Joel Brobecker wrote:
> > In the long term, if we can get GDB to use Dwarf 2 CFI and location
> > lists, there will be no difference between setting breakpoints before
> > or after the prologue.  The prologue scanning and skipping behavior
> > will only be necessary in the absence of that debugging info.
> 
> I agree.
> 
> In the meantime, may I suggest we install Jim Ingham's patch? I think
> the new behavior would be more useful than the current, but maybe I'm
> wrong?
> 
> Another alternative that has been discussed at ACT is to move the line
> where the function declaration is located to an address immediately
> past the function prologue. And the prologue would get a separate line
> info entry with a line number set to 0. The rationale behind modifying
> the compiler is that the compiler knows much better than GDB what part
> of the code is the prologue, and therefore should be in a better
> position of to provide accurate line information.
> 
> But I personally (ie I'm not speaking for ACT) prefer changing GDB. What
> do you think?

I don't like adding yet another meaning to line-number-0 very much; it
has a defined meaning in GDB, which is "not part of a function".

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Jim Blandy]

Joel Brobecker <brobecker@gnat.com> writes:
> Another alternative that has been discussed at ACT is to move the line
> where the function declaration is located to an address immediately
> past the function prologue. And the prologue would get a separate line
> info entry with a line number set to 0. The rationale behind modifying
> the compiler is that the compiler knows much better than GDB what part
> of the code is the prologue, and therefore should be in a better
> position of to provide accurate line information.

There's already a convention for this, I think.  Now, where was it
described???  Here it is:

int
in_prologue (CORE_ADDR pc, CORE_ADDR func_start)
{
  struct symtab_and_line sal;
  CORE_ADDR func_addr, func_end;

  /* We have several sources of information we can consult to figure
     this out.
     - Compilers usually emit line number info that marks the prologue
       as its own "source line".  So the ending address of that "line"
       is the end of the prologue.  If available, this is the most
       reliable method.
     - The minimal symbols and partial symbols, which can usually tell
       us the starting and ending addresses of a function.
     - If we know the function's start address, we can call the
       architecture-defined SKIP_PROLOGUE function to analyze the
       instruction stream and guess where the prologue ends.
     - Our `func_start' argument; if non-zero, this is the caller's
       best guess as to the function's entry point.  At the time of
       this writing, handle_inferior_event doesn't get this right, so
       it should be our last resort.  */

So, just emit an extra line entry for the prologue.

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

[Joel Brobecker]

> There's already a convention for this, I think.  Now, where was it
> described???  Here it is:
> 
> int
> in_prologue (CORE_ADDR pc, CORE_ADDR func_start)
> {
>   struct symtab_and_line sal;
>   CORE_ADDR func_addr, func_end;
> 
>   /* We have several sources of information we can consult to figure
>      this out.
>      - Compilers usually emit line number info that marks the prologue
>        as its own "source line".  So the ending address of that "line"
>        is the end of the prologue.  If available, this is the most
>        reliable method.
[...]
> So, just emit an extra line entry for the prologue.

If I understand the description above correctly, emitting a new line
entry for the prologue shouldn't be necessary. A glance at the
implemenation seems to confirm it. Basically, this function performs
the following actions:

  - try to find the function containing a given PC address, to get
    the address of the begining of the function
    
  - from the start of function address, it tries to find a line entry.

  - If it found a line entry, it uses the end address as the end of the
    prologue.

GCC already generates this line entry. I don't know if it was generated
for this exact purpose but consider the example:

    5  int
    6  main (void)
    7  {
    8    return 0;
    9  }

GCC will generate a line entry for line 7 which will point at the
begining of the prologue of main. The next line entry is for the first
real line of code, so the prologue ends up having its own source line.
Here is a dump from the assembly file generated by a recent version of
GCC on x86-linux:

    main:
            .stabn 68,0,7,.LM1-main
    .LM1:
            pushl   %ebp
            movl    %esp, %ebp
            subl    $8, %esp
            andl    $-16, %esp
            movl    $0, %eax
            subl    %eax, %esp
            .stabn 68,0,8,.LM2-main
    .LM2:
            movl    $0, %eax
            .stabn 68,0,9,.LM3-main
    .LM3:
            leave
            ret

The trouble is that, when using "break file:line", GDB does not use this
kind of information to skip the prologue, it does not even try to skip
it.

So far, I see the following 2 ways out:

  1. We move line 7 to .LM2. But then we have a small problem, because
     the prologue instructions become orphaned (no line number
     associated). This may cause a bit of grief to the developpers that
     sometimes step into the function prologue. This is why we suggested
     setting the line number to 0. But this is also a bit weak, because
     how is the debugger going to relate this line 0 to the appropriate
     line number in the source?

  2. We leave line 7 at .LM1 (ie the begining of the function, at the
     begining of the prologue), but then GDB a putting a breakpoint
     at line 7 will cause GDB to stop before the prologue (actually, if
     it ever stops, remember the case of Tru64 where the first 2
     instructions in the prologue setting the gp are often optimized
     out, thank you mister linker).

In this case, the most sensible change for me seems to modify GDB to
skip prologues when putting breakpoints by line number. The idea of
modifying the compiler was that the compiler would help GDB locating the
bounds of the prologue, but it seems that the information is already
there. So no change in the compiler is warranted anymore. Only GDB needs
to be upgraded to take advantage of it. We could also use this
information when putting a breakpoint by function name. This is where my
"BTW:" below becomes interesting.

Does this seem a reasonable approach?

-- 
Joel

BTW:

In fact, I wonder if there is a function somewhere that returns the
address of the first instruction past the prologue that uses this
algorithm? In all the places I've looked, we usually use SKIP_PROLOGUE.
See for instance find_function_start_sal which uses SKIP_PROLOGUE as its
sole method to find the first real instruction address.

Should I suggest that we write a small function generic_skip_prologue
that does exactly what in_prologue does, execpt that it returns the
address of first instruction past the prologue, rather than returning
just an indication whether we are in the prologue or not. in_prologue
can then be implemented by invoking generic_skip_prologue and checking
whether the returned address is equal to the initial pc address.

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

[Jim Blandy]

For as long as I can remember, GDB has treated setting a breakpoint on
the line containing the opening curly brace of a function's block as
meaning `set a breakpoint before the prologue'.  I've always assumed
that was deliberate behavior.

But I can't find it documented in the GDB manual.  And it's a lousy
user interface (`break *main' works just as well, and makes more sense
to me).  Maybe the behavior is just a side effect of the decision to
attribute the prologue code to the line containing the opening curly
brace --- if the program stops in the prologue, that's as sensible a
place as any to claim it's at.

So I'd support changing `break LINENO' to always skip the prologue.

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

[Michael Snyder]

Jim Blandy wrote:
> 
> For as long as I can remember, GDB has treated setting a breakpoint on
> the line containing the opening curly brace of a function's block as
> meaning `set a breakpoint before the prologue'.  I've always assumed
> that was deliberate behavior.

Semi.  It follows from the line symbols.  GCC emits a line symbol
for that line which spans the address range of the prologue.  So
you could say it's deliberate -- but on GCC's part, rather than
on GDB's.

> But I can't find it documented in the GDB manual. 

That's because it's not a special case.  It's the same
behavior as for any line -- put the breakpoint where 
the compiler says to.

> And it's a lousy
> user interface (`break *main' works just as well, and makes more sense
> to me).  Maybe the behavior is just a side effect of the decision to
> attribute the prologue code to the line containing the opening curly
> brace 

Exactly -- 

> --- if the program stops in the prologue, that's as sensible a
> place as any to claim it's at.
> 
> So I'd support changing `break LINENO' to always skip the prologue.

I would not.  It's changing a behavior that people have 
become accustomed to.

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

[Jim Blandy]

Michael Snyder <msnyder@redhat.com> writes:
> > So I'd support changing `break LINENO' to always skip the prologue.
> 
> I would not.  It's changing a behavior that people have 
> become accustomed to.

Well, that alone isn't a good reason to keep a behavior, is it?  I
mean, it's pretty confusing.  And there's a good alternative.