This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch master updated. 5ce0145de764dc9c6e92daf2f843fa6e496c49d0


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  5ce0145de764dc9c6e92daf2f843fa6e496c49d0 (commit)
      from  e234935207c21a212b5a35928f50b578c65b9649 (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=5ce0145de764dc9c6e92daf2f843fa6e496c49d0

commit 5ce0145de764dc9c6e92daf2f843fa6e496c49d0
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Dec 17 20:47:36 2013 +0000

    "tfind" across unavailable-stack frames.
    
    Like when stepping, the current stack frame location is expected to be
    printed as result of tfind command, if that results in moving to a
    different function.  In tfind_1 we see:
    
      if (from_tty
          && (has_stack_frames () || traceframe_number >= 0))
        {
          enum print_what print_what;
    
          /* NOTE: in imitation of the step command, try to determine
             whether we have made a transition from one function to
             another.  If so, we'll print the "stack frame" (ie. the new
             function and it's arguments) -- otherwise we'll just show the
             new source line.  */
    
          if (frame_id_eq (old_frame_id,
                           get_frame_id (get_current_frame ())))
            print_what = SRC_LINE;
          else
            print_what = SRC_AND_LOC;
    
          print_stack_frame (get_selected_frame (NULL), 1, print_what, 1);
          do_displays ();
        }
    
    However, when we haven't collected any registers in the tracepoint
    (collect $regs), that doesn't actually work:
    
     (gdb) tstart
     (gdb) info tracepoints
     Num     Type           Disp Enb Address    What
     1       tracepoint     keep y   0x080483b7 in func0
                                                at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
             collect testload
         installed on target
     2       tracepoint     keep y   0x080483bc in func1
                                                at ../.././../git/gdb/testsuite/gdb.trace/circ.c:32
             collect testload
         installed on target
     (gdb) c
     Continuing.
    
     Breakpoint 3, end () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:72
     72    }
     (gdb) tstop
     (gdb) tfind start
     Found trace frame 0, tracepoint 1
     #0  func0 () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
     28    }
     (gdb) tfind
     Found trace frame 1, tracepoint 2
     32    }
     (gdb)
    
    When we don't have info about the stack available
    (UNWIND_UNAVAILABLE), frames end up with outer_frame_id as frame ID.
    And in the scenario above, the issue is that both frames before and
    after the second tfind (the frames for func0 an func1) have the same
    id (outer_frame_id), so the frame_id_eq check returns false, even
    though the frames were of different functions.  GDB knows that,
    because the PC is inferred from the tracepoint's address, even if no
    registers were collected.
    
    To fix this, this patch adds support for frame ids with a valid code
    address, but <unavailable> stack address, and then makes the unwinders
    use that instead of the catch-all outer_frame_id for such frames.  The
    frame_id_eq check in tfind_1 then automatically does the right thing
    as expected.
    
    I tested with --directory=gdb.trace/ , before/after the patch, and
    compared the resulting gdb.logs, then adjusted the tests to expect the
    extra output that came out.  Turns out that was only circ.exp, the
    original test that actually brought this issue to light.
    
    Tested on x86_64 Fedora 17, native and gdbserver.
    
    gdb/
    2013-12-17  Pedro Alves  <palves@redhat.com>
    
    	* frame.h (enum frame_id_stack_status): New enum.
    	(struct frame_id) <stack_addr>: Adjust comment.
    	<stack_addr_p>: Delete field, replaced with ...
    	<stack_status>: ... this new field.
    	(frame_id_build_unavailable_stack): Declare.
    	* frame.c (frame_addr_hash, fprint_field, outer_frame_id)
    	(frame_id_build_special): Adjust.
    	(frame_id_build_unavailable_stack): New function.
    	(frame_id_build, frame_id_build_wild): Adjust.
    	(frame_id_p, frame_id_eq, frame_id_inner): Adjust to take into
    	account frames with unavailable stack.
    
    	* amd64-tdep.c (amd64_frame_this_id)
    	(amd64_sigtramp_frame_this_id, amd64_epilogue_frame_this_id): Use
    	frame_id_build_unavailable_stack.
    	* dwarf2-frame.c (dwarf2_frame_this_id): Likewise.
    	* i386-tdep.c (i386_frame_this_id, i386_epilogue_frame_this_id)
    	(i386_sigtramp_frame_this_id):  Likewise.
    
    gdb/testsuite/
    2013-12-17  Pedro Alves  <palves@redhat.com>
    
    	* gdb.trace/circ.exp: Expect frame info to be printed when
    	switching between frames with unavailable stack, but different
    	functions.

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

Summary of changes:
 gdb/ChangeLog                    |   21 ++++++++++++++
 gdb/amd64-tdep.c                 |   32 +++++++++++++---------
 gdb/dwarf2-frame.c               |    9 +++---
 gdb/frame.c                      |   54 ++++++++++++++++++++++++++++----------
 gdb/frame.h                      |   30 +++++++++++++++++++--
 gdb/i386-tdep.c                  |   33 ++++++++++++++---------
 gdb/testsuite/ChangeLog          |    6 ++++
 gdb/testsuite/gdb.trace/circ.exp |    4 +-
 8 files changed, 139 insertions(+), 50 deletions(-)


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]