diff options
author | Andrew Burgess <aburgess@broadcom.com> | 2014-05-28 23:34:43 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@broadcom.com> | 2014-05-30 22:44:36 +0100 |
commit | 53e8a631a0c26a162caa6e98dc568be696e506e5 (patch) | |
tree | e1ffcc30793f51d0edd4b903e9921fb65423bb58 /gdb/frame.h | |
parent | 70e38b8e988c7db764a7344f0d27273706543a54 (diff) | |
download | gdb-53e8a631a0c26a162caa6e98dc568be696e506e5.zip gdb-53e8a631a0c26a162caa6e98dc568be696e506e5.tar.gz gdb-53e8a631a0c26a162caa6e98dc568be696e506e5.tar.bz2 |
Add a TRY_CATCH to get_prev_frame_always to better manage errors during unwind.
https://sourceware.org/ml/gdb-patches/2014-05/msg00737.html
Currently a MEMORY_ERROR raised during unwinding a frame will cause the
unwind to stop with an error message, for example:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
Cannot access memory at address 0x2aaaaaab0000
However, frame #4 is marked as being the end of the stack unwind, so a
subsequent request for the backtrace looses the error message, such as:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
When fetching the backtrace, or requesting the stack depth using the MI
interface the situation is even worse, the first time a request is made
we encounter the memory error and so the MI returns an error instead of
the correct result, for example:
(gdb) -stack-info-depth
^error,msg="Cannot access memory at address 0x2aaaaaab0000"
Or,
(gdb) -stack-list-frames
^error,msg="Cannot access memory at address 0x2aaaaaab0000"
However, once one of these commands has been used gdb has, internally,
walked the stack and figured that out that frame #4 is the bottom of the
stack, so the second time an MI command is tried you'll get the "expected"
result:
(gdb) -stack-info-depth
^done,depth="5"
Or,
(gdb) -stack-list-frames
^done,stack=[frame={level="0", .. snip lots .. }]
After this patch the MEMORY_ERROR encountered during the frame unwind is
attached to frame #4 as the stop reason, and is displayed in the CLI each
time the backtrace is requested. In the MI, catching the error means that
the "expected" result is returned the first time the MI command is issued.
So, from the CLI the results of the backtrace will be:
(gdb) bt
#0 breakpt () at amd64-invalid-stack-middle.c:27
#1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32
#2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38
#3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44
#4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50
Backtrace stopped: Cannot access memory at address 0x2aaaaaab0000
Each and every time that the backtrace is requested, while the MI output
will similarly be consistently:
(gdb) -stack-info-depth
^done,depth="5"
Or,
(gdb) -stack-list-frames
^done,stack=[frame={level="0", .. snip lots .. }]
gdb/ChangeLog:
* frame.c (struct frame_info): Add stop_string field.
(get_prev_frame_always_1): Renamed from get_prev_frame_always.
(get_prev_frame_always): Old content moved into
get_prev_frame_always_1. Call get_prev_frame_always_1 inside
TRY_CATCH, handle MEMORY_ERROR exceptions.
(frame_stop_reason_string): New function definition.
* frame.h (unwind_stop_reason_to_string): Extend comment to
mention frame_stop_reason_string.
(frame_stop_reason_string): New function declaration.
* stack.c (frame_info): Switch to frame_stop_reason_string.
(backtrace_command_1): Switch to frame_stop_reason_string.
* unwind_stop_reason.def: Add UNWIND_MEMORY_ERROR.
(LAST_ENTRY): Changed to UNWIND_MEMORY_ERROR.
* guile/lib/gdb.scm: Add FRAME_UNWIND_MEMORY_ERROR to export list.
gdb/doc/ChangeLog:
* guile.texi (Frames In Guile): Mention FRAME_UNWIND_MEMORY_ERROR.
* python.texi (Frames In Python): Mention
gdb.FRAME_UNWIND_MEMORY_ERROR.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-invalid-stack-middle.exp: Update expected results.
* gdb.arch/amd64-invalid-stack-top.exp: Likewise.
Diffstat (limited to 'gdb/frame.h')
-rw-r--r-- | gdb/frame.h | 15 |
1 files changed, 14 insertions, 1 deletions
diff --git a/gdb/frame.h b/gdb/frame.h index 79881521d..59564f9 100644 --- a/gdb/frame.h +++ b/gdb/frame.h @@ -501,10 +501,23 @@ enum unwind_stop_reason enum unwind_stop_reason get_frame_unwind_stop_reason (struct frame_info *); -/* Translate a reason code to an informative string. */ +/* Translate a reason code to an informative string. This converts the + generic stop reason codes into a generic string describing the code. + For a possibly frame specific string explaining the stop reason, use + FRAME_STOP_REASON_STRING instead. */ const char *unwind_stop_reason_to_string (enum unwind_stop_reason); +/* Return a possibly frame specific string explaining why the unwind + stopped here. E.g., if unwinding tripped on a memory error, this + will return the error description string, which includes the address + that we failed to access. If there's no specific reason stored for + a frame then a generic reason string will be returned. + + Should only be called for frames that don't have a previous frame. */ + +const char *frame_stop_reason_string (struct frame_info *); + /* Unwind the stack frame so that the value of REGNUM, in the previous (up, older) frame is returned. If VALUEP is NULL, don't fetch/compute the value. Instead just return the location of the |