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

[Jim Ingham <jingham@apple.com>]

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