This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.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 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...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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |