"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.

0 files changed, 0 insertions, 0 deletions