[RFC] breakpoints and function prologues...
Jim Ingham
jingham@apple.com
Fri Aug 23 10:50:00 GMT 2002
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
More information about the Gdb-patches
mailing list