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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
