forked from Imagelibrary/binutils-gdb
53e8a631a0
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.