[Bug breakpoints/27394] New: Breakpoint set on vector code but not serial code within a lexical scope

["i at maskray dot me" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27394

            Bug ID: 27394
           Summary: Breakpoint set on vector code but not serial code
                    within a lexical scope
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: i at maskray dot me
  Target Milestone: ---

int Foo(const int iterations, const int initial) {
  static int val = initial;

  for (int i = 0; i <= iterations; ++i)
    val += (i % 2 ? 50 : 25) * i;  // If you set a breakpoint on this line, it
will not get hit

  return val;
}

int main(int argc, char**) {
  return Foo(4 + argc, 5 + argc);
}


clang++ -g -fno-inline -O2 a.cc
# g++ -g -fno-inline -O3 a.cc  is similar. clang enables vectorization with -O2
gdb ./a.out -batch -ex 'b 5' -ex 'r'

The breakpoint is not triggered. (lldb has the same problem.)
The problem is that we have a vector code path (smaller address) and a serial
code path (larger address) under the same lexical scope.
The serial code path does not get a breakpoint.


gdb/linespec.c:2173 has such a comment

      /* For optimized code, the compiler can scatter one source line
         across disjoint ranges of PC values, even when no duplicate
         functions or inline functions are involved.  For example,
         'for (;;)' inside a non-template, non-inline, and non-ctor-or-dtor
         function can result in two PC ranges.  In this case, we don't
         want to set a breakpoint on the first PC of each range.  To filter
         such cases, we use containing blocks -- for each PC found
         above, we see if there are other PCs that are in the same
         block.  If yes, the other PCs are filtered out.  */

intermediate_results.size() is 4, matching the output of

  % llvm-dwarfdump -debug-line ./a.out | grep ' 5 .*is_stmt'
  # loop preheader for the vector code path
  0x00000000004011e9      5     13      1   0             0  is_stmt
  0x00000000004012ba      5     13      1   0             0  is_stmt
  # loop preheader for the serial code path
  0x0000000000401360      5     13      1   0             0  is_stmt
  0x0000000000401377      5      9      1   0             0  is_stmt

blocks[*] values are the same, presumably because after considering
DW_TAG_inlined_subroutine/DW_TAG_lexical_block (what else?),
the four addresses are in the same scope.
After deduplication, only the first address gets a breakpoint.

-- 
You are receiving this mail because:
You are on the CC list for the bug.