binutils-gdb/gdb/unwind_stop_reasons.def
Andrew Burgess 53e8a631a0 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.
2014-05-30 22:44:36 +01:00

80 lines
2.8 KiB
Modula-2

/* Copyright (C) 2011-2014 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
/* Reasons why frames could not be further unwound
SET (name, description)
After this reason name, all reasons should be considered errors;
i.e.: abnormal stack termination.
FIRST_ERROR (name)
First and Last reason defined
FIRST_ENTRY (name)
LAST_ENTRY (name) */
#ifdef SET
/* No particular reason; either we haven't tried unwinding yet,
or we didn't fail. */
SET (UNWIND_NO_REASON, "no reason")
/* This is no longer used anywhere, but it's kept because it's exposed
to Python. This is how GDB used to indicate end of stack. We've
now migrated to a model where frames always have a valid ID. */
SET (UNWIND_NULL_ID, "unwinder did not report frame ID")
/* This frame is the outermost. */
SET (UNWIND_OUTERMOST, "outermost")
/* Can't unwind further, because that would require knowing the
values of registers or memory that haven't been collected. */
SET (UNWIND_UNAVAILABLE, \
"not enough registers or memory available to unwind further")
/* This frame ID looks like it ought to belong to a NEXT frame,
but we got it for a PREV frame. Normally, this is a sign of
unwinder failure. It could also indicate stack corruption. */
SET (UNWIND_INNER_ID, "previous frame inner to this frame (corrupt stack?)")
/* This frame has the same ID as the previous one. That means
that unwinding further would almost certainly give us another
frame with exactly the same ID, so break the chain. Normally,
this is a sign of unwinder failure. It could also indicate
stack corruption. */
SET (UNWIND_SAME_ID, "previous frame identical to this frame (corrupt stack?)")
/* The frame unwinder didn't find any saved PC, but we needed
one to unwind further. */
SET (UNWIND_NO_SAVED_PC, "frame did not save the PC")
/* There was an error accessing memory while unwinding this frame. */
SET (UNWIND_MEMORY_ERROR, "memory error while unwinding")
#endif /* SET */
#ifdef FIRST_ERROR
FIRST_ERROR (UNWIND_UNAVAILABLE)
#endif
#ifdef FIRST_ENTRY
FIRST_ENTRY (UNWIND_NO_REASON)
#endif
#ifdef LAST_ENTRY
LAST_ENTRY (UNWIND_MEMORY_ERROR)
#endif