[Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

Also, FWIW, the other gdb test suite failures we saw were:

  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

Those last two are different versions of this original issue seen in break.exp/c with multi-line conditionals.

The foll-exec.exp ones I'm less sure of - Looks like maybe it's a similar line table attribution sort of thing, but it leads the test case not to step across the intended process boundary/exec call and things go weird from there.

Yeah, it boils down to something like this:

  void f1(const char*, const char*) { }
  int main() {
    char prog[1];
  
    f1(prog,
       prog);
  }

Without the patch, you step to the 'f1' line, and then step into or over the function call (step or next).
But with these patches applied - you step to the 'f1(' line, then the 'prog);' line, then back to the 'f1(' line, then into/over the function call.

Again, could be acceptable - if those arguments had specific non-trivial code in them (like other function calls) you'd certainly get that step forward/backward behavior - but it's notewhorthy that this is change would make more cases like that & it'd be good to understand why/if that's a good thing overall.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91734/new/

https://reviews.llvm.org/D91734