gdb and binutils branch master updated. 53e8a631a0c26a162caa6e98dc568be696e506e5

[aburgess at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  53e8a631a0c26a162caa6e98dc568be696e506e5 (commit)
       via  70e38b8e988c7db764a7344f0d27273706543a54 (commit)
       via  938f0e2f6766e90a5ddc5df00e97a68873fd1252 (commit)
      from  f6fb832249b8c64e9c35571fdabc323a62ad31fa (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=53e8a631a0c26a162caa6e98dc568be696e506e5

commit 53e8a631a0c26a162caa6e98dc568be696e506e5
Author: Andrew Burgess <aburgess@broadcom.com>
Date:   Wed May 28 23:34:43 2014 +0100

    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.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=70e38b8e988c7db764a7344f0d27273706543a54

commit 70e38b8e988c7db764a7344f0d27273706543a54
Author: Andrew Burgess <aburgess@broadcom.com>
Date:   Wed May 28 22:46:33 2014 +0100

    Rename frame_stop_reason_string to unwind_stop_reason_to_string.
    
      https://sourceware.org/ml/gdb-patches/2014-05/msg00721.html
    
    This function is confusingly named, the "frame_" in the name implies it
    somehow is frame dependent, when in reality the function just converts an
    'enum unwind_stop_reason' value to a string.
    
    gdb/ChangeLog:
    
    	* frame.c (frame_stop_reason_string): Rename to ...
    	(unwind_stop_reason_to_string): this.
    	* frame.h (frame_stop_reason_string): Rename to ...
    	(unwind_stop_reason_to_string): this.
    	* stack.c (frame_info): Update call to frame_stop_reason_string.
    	(backtrace_command_1): Likewise.
    	* guile/scm-frame.c (gdbscm_unwind_stop_reason_string): Likewise.
    	* python/py-frame.c (gdbpy_frame_stop_reason_string): Likewise.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=938f0e2f6766e90a5ddc5df00e97a68873fd1252

commit 938f0e2f6766e90a5ddc5df00e97a68873fd1252
Author: Andrew Burgess <aburgess@broadcom.com>
Date:   Wed Apr 2 17:02:51 2014 +0100

    Remove previous frame if an error occurs when computing frame id during unwind.
    
      https://sourceware.org/ml/gdb-patches/2014-05/msg00712.html
    
    If an error is thrown during computing a frame id then the frame is left
    in existence but without a valid frame id, this will trigger internal
    errors if/when the frame is later visited (for example in a backtrace).
    
    This patch catches errors raised while computing the frame id, and
    arranges for the new frame, the one without a frame id, to be removed
    from the linked list of frames.
    
    gdb/ChangeLog:
    
    	* frame.c (remove_prev_frame): New function.
    	(get_prev_frame_if_no_cycle): Create / discard cleanup using
    	remove_prev_frame.
    
    gdb/testsuite/ChangeLog:
    
    	* gdb.arch/amd64-invalid-stack-middle.S: New file.
    	* gdb.arch/amd64-invalid-stack-middle.c: New file.
    	* gdb.arch/amd64-invalid-stack-middle.exp: New file.
    	* gdb.arch/amd64-invalid-stack-top.c: New file.
    	* gdb.arch/amd64-invalid-stack-top.exp: New file.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                                      |   34 +
 gdb/doc/ChangeLog                                  |    6 +
 gdb/doc/guile.texi                                 |    3 +
 gdb/doc/python.texi                                |    3 +
 gdb/frame.c                                        |  128 ++-
 gdb/frame.h                                        |   17 +-
 gdb/guile/lib/gdb.scm                              |    1 +
 gdb/guile/scm-frame.c                              |    2 +-
 gdb/python/py-frame.c                              |    2 +-
 gdb/stack.c                                        |    4 +-
 gdb/testsuite/ChangeLog                            |   14 +
 .../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 |   80 ++
 gdb/unwind_stop_reasons.def                        |    5 +-
 17 files changed, 1920 insertions(+), 29 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


hooks/post-receive
-- 
gdb and binutils