Re: [RFA] unexpected multiple location for breakpoint

[Joel Brobecker <brobecker@adacore.com>]

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