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