[PATCH v3 0/4] Catch errors in get_prev_frame.

[Andrew Burgess <aburgess at broadcom dot com>]

This V3 patch completely replaces the previous patch posted here:
  https://sourceware.org/ml/gdb-patches/2014-04/msg00064.html
Which due to a series of blunders is pretty much unreviewable. The content
of this series is identical to the previous attempts but the patches should
be correctly formatted, and the email text description is included too.

Patch Description:

While working on a reproducer for this patch:
  https://sourceware.org/ml/gdb-patches/2014-03/msg00629.html

I ran into a few other issues.  The route cause of the problems I'm seeing
is that not all errors thrown within get_prev_frame are caught.  This
causes a couple of problems,

1. For the MI this means that commands like -stack-info-depth will
return an error rather than a result.  Even more annoying, is that
depending on where in the process the error is thrown enough state may
be left set that the /next/ time -stack-info-depth is asked, the correct
result is given!

2. For standard CLI backtraces our the results are (I think) inconsistent,
so for example some backtraces will end with a message like: "Backtrace
stopped: previous frame inner to this frame (corrupted stack?)", this
message will be displayed every time the backtrace is requested, in other
cases though, the reason is only displayed the first time a backtrace is
requested, this is the case when an uncaught error causes the backtrace to
stop, also in the uncaught error case the "Backtrace stopped" prefix does
not appear.

This patch set tries to fix both these issues by holding a frame specific
string that describes why the backtrace stopped at this frame (only for the
last frame in the backtrace obviously).  If this string is not set then we
still use the existing generic strings.

A new TRY_CATCH inside get_prev_frame catches (currently) all unhandled
errors, the error message from these errors is then used as a frame
specific stop reason string.  There's a new unwind_stop_reason code for
this case, UNWIND_MISC_ERROR.

If it's felt that catching all errors like this is too much then I could
soften this to just catching MEMORY_ERRORs, as right now the problems I'm
seeing all relate to accessing memory through a corrupted stack pointer.

Thanks,
Andrew



Andrew Burgess (4):
  New test for backtrace when the stack pointer is invalid (inaccessible).
  Remove previous frame if an error occurs when computing frame id during unwind.
  Deprecate frame_stop_reason_string.
  Add a TRY_CATCH to get_prev_frame to better handle errors during unwind.

 gdb/frame.c                                        |  123 +-
 gdb/frame.h                                        |   11 +-
 gdb/guile/scm-frame.c                              |    2 +-
 gdb/python/py-frame.c                              |    2 +-
 gdb/stack.c                                        |    4 +-
 .../gdb.arch/amd64-invalid-stack-middle.S          | 1410 ++++++++++++++++++++
 .../gdb.arch/amd64-invalid-stack-middle.c          |   89 ++
 .../gdb.arch/amd64-invalid-stack-middle.exp        |   78 ++
 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.c   |   73 +
 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp |   81 ++
 gdb/unwind_stop_reasons.def                        |    5 +-
 11 files changed, 1850 insertions(+), 28 deletions(-)
 create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.S
 create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c
 create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp
 create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.c
 create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp

-- 
1.8.1.3