dblaikie added a comment. This causes several regressions in the gdb test suite we're running internally - the failures are:
FAIL: gdb.base/break.exp: breakpoint at start of multi line while conditional FAIL: gdb.base/break.exp: breakpoint info FAIL: gdb.base/foll-exec.exp: step through execlp call FAIL: gdb.base/foll-exec.exp: step after execlp call FAIL: gdb.base/foll-exec.exp: print execd-program/global_i (after execlp) FAIL: gdb.base/foll-exec.exp: print execd-program/local_j (after execlp) FAIL: gdb.base/foll-exec.exp: print follow-exec/local_k (after execlp) FAIL: gdb.base/hbreak2.exp: hardware breakpoint at start of multi line while conditional FAIL: gdb.base/hbreak2.exp: hardware breakpoint info I looked into the first one in break.exp and reduced it a bit, given code like this: int main() { } int f1(int a, int b) { return a && b; } debugging this binary with gdb and running `b f1` results in breaking on an instruction with no line information after this change, eg: old behavior: (gdb) b f1 Breakpoint 1 at 0x40112c: file test.c, line 2. new behavior: (gdb) b f1 Breakpoint 1 at 0x40112a The assembly difference: - xorl %eax, %eax - # kill: def $al killed $al killed $eax movl %edi, -4(%rbp) movl %esi, -8(%rbp) .Ltmp2: - .loc 1 3 10 prologue_end # break.c:3:10 + .loc 1 0 0 prologue_end # break.c:0:0 + xorl %eax, %eax + # kill: def $al killed $al killed $eax + .loc 1 3 10 # break.c:3:10 cmpl $0, -4(%rbp) movb %al, -9(%rbp) # 1-byte Spill So it looks like the && caused a location-less zero constant to be synthesized and that previously floated up into the prologue - but now it's pulled down past the prologue begin, so after the prologue this location-less zero is the first location. I've reverted this patch (& dependent/follow-on patches) in 615f63e149f31d6a97b5233b4fe634db92e19aa9 <https://reviews.llvm.org/rG615f63e149f31d6a97b5233b4fe634db92e19aa9> - happy to help with further reproductions/validations (if/when you've got a proposed fix, if you can't run the gdb test suite or otherwise reproduce the failures, I can run our internal infrastructure to validate again) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91734/new/ https://reviews.llvm.org/D91734 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits