[Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction
Paul Robinson via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Dec 14 14:48:34 PST 2020
probinson added a comment.
I've run this through our copy of the GDB suite (8.3, not sure how old that is). There are 10 differences, with and without the patch.
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)
These 5 are all adjacent test points; what happens is that a "next" ends up stepping through parameter evaluation of a call to execl(), where the test expects it to execute the call. Adding two more "next" commands should fix that.
FAIL: gdb.base/call-ar-st.exp: check args of sum_array_print
FAIL: gdb.base/funcargs.exp: continue to call2i
FAIL: gdb.base/funcargs.exp: backtrace from call7k (pattern 1)
These three are all cases where a function parameter list is long enough to require parameters to be passed on the stack. In that situation, prologue_end is being set *way* too early, and so breaking on the function will stop before the parameters have all been homed. Garbage ensues. Haven't gotten to the bottom of that yet.
The news is not all bad. These two changed to PASS:
UNTESTED: gdb.base/break-caller-line.exp: target arch has an instruction after call as part of the caller line
FAIL: gdb.python/python.exp: test find_pc_line with resume address
CHANGES SINCE LAST ACTION
More information about the lldb-commits