[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



More information about the lldb-commits mailing list