[RFA] unexpected multiple location for breakpoint
Joel Brobecker
brobecker@adacore.com
Wed Dec 29 06:08:00 GMT 2010
> > If this is a bug, then the only solution I can think of is inserting
> > a breakpoint at *every* instances of line 53, regardless of
> > lexical-block relationships.
>
> When would that be worse than what we have now?
I worry about the effect at -O0. It is common to see the same source
line being split across the code. For instance, with conditional
loops, the condition evaluation is often placed at the end of the
loop, and its code is associated to the initial line.
See Eg. gdb.base/call-ar-st.c, where we have:
1146 int main () {
[bunch of declarations snipped]
1193 /* Initialize arrays
1194 */
1195 for (index = 0; index < 120; index++) {
1196 if ((index%2) == 0) char_array[index] = 'Z';
1197 else char_array[index] = 'a';
1198 }
If we try to insert a breakpoint on line 1195, we get:
(gdb) break call-ar-st.c:1195
Breakpoint 1: file /[...]/call-ar-st.c, line 1195. (2 locations)^M
Inspecting the line table, we find that it looks like this: 1195, 1196,
1197, and then back to 1195. So the double-location breakpoint is
expected if we decide to break everywhere.
There is a slight side-issue with my patch where breaking on "main"
also causes 2 breakpoints to be inserted, but I consider that a buglet
because we have special logic to avoid the expansion when breaking on
a function (or so I thought!).
(gdb) b main
Breakpoint 1 at 0x401906: file /[...]/call-ar-st.c, line 1195. (2 locations)
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000401906 in main
at call-ar-st.c:1195
1.2 y 0x000000000040193f in main
at call-ar-st.c:1195
Note that we also have the following explicit comment in the code:
/* For optimized code, compiler can scatter one source line accross
disjoint ranges of PC values, even when no duplicate functions
or inline functions are involved. For example, 'for (;;)' inside
non-template non-inline non-ctor-or-dtor function can result
in two PC ranges. In this case, we don't want to set breakpoint
on first PC of each range. [...] */
For the record, attached is the patch that I used. It was written on
top of the initially proposed patch (in this thread), but just purely
for convenience. The piece that checks the next entry is to avoid
inserting a breakpoint on 2 blocks if the two blocks are consecutive.
This is often the case with functions where the compiler emits a line
entry with the same line number to mark the end of the function prologue...
--
Joel
More information about the Gdb-patches
mailing list