[PATCH] D91734: [FastISel] Flush local value map on every instruction
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 3 20:56:18 PST 2020
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
More information about the llvm-commits
mailing list