Re: [PATCH 3/3] Select the current frame in command tdump.

[Pedro Alves <palves at redhat dot com>]

On 06/27/2013 03:02 PM, Yao Qi wrote:
> Command 'tdump' should be run on the current stack frame instead of
> the selected stack frame. 

Thanks.

> This patch is to change to the current
> stack trace when executing command 'tdump'.
> 
> This patch also adds a test in gdb.trace/backtrace.exp, to test
> 'tdump' on frame 0 and frame 1 respectively. If only test
> part of patch is applied, we'll get a fail:
> 
> Data collected at tracepoint 6, trace frame 4:^M
> $ebp = (void *) 0xbfffe7c8^M
> (*(void **) ($esp)) @ 64 = {0x3, 0x2, 0x3, 0x4, 0x5, 0x5, 0x6,
> 0x4cf0d152 <handle_intel+146>, 0xbfffe7cf, 0x0, 0x8a18d300,
> 0xbfffe7a0, 0x8, 0xbfffe7a3, 0x80487c0, 0x80487b4, 0xf0b2ff,
> 0x8048243, 0xca0000, 0x4d01cff4, 0x0, 0x0, 0xbfffe818, 0x80486c7
> <main+62>, 0xbfffe7e4, 0x8049abc, 0x1, 0x80482cd <_init+41>,
> 0x4d01b1b4, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa,
> 0x80486e0 <__libc_csu_init>, 0x0, 0x0, 0x4ce896b3
> <__libc_start_main+243>, 0x1, 0xbfffe8b4, 0xbfffe8bc, 0x4ce6cfc4,
> <unavailable> <unavailable>, <unavailable>, <unavailable>,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> <unavailable>, <unavailable>, <unavailable>, <unavailable>,
> <unavailable>, <unavailable>, <unavailable>, <unavailable>,
> <unavailable>, <unavailable>, <unavailable>, <unavailable>,
> <unavailable>}
> ^^^^^^^^^^^^^^
> (gdb) FAIL: gdb.trace/backtrace.exp: traceframe 4: tdump on frame 1
> 
> as we can see, "<unavailable>" is unexpected.  With all the patch
> applied, the fail is fixed, and we'll see that no "<unavailable>"
> appeared in the output.
> 
> Data collected at tracepoint 6, trace frame 4:^M
> $ebp = (void *) 0xbfffe768^M
> (*(void **) ($esp)) @ 64 = {0xbfffe810, 0x4ce55a39
> <_dl_lookup_symbol_x+265>, 0xbfffe7f0, 0x80481cc, 0xbfffe7d8,
> 0x4ce6da54, 0x0, 0xb7ffeca8, 0x1, 0x0, 0x1, 0x1, 0x0, 0x0, 0xbfffe7c8,
> 0x80485fc <gdb_c_test+450>, 0x3, 0x2, 0x3, 0x4, 0x5, 0x5, 0x6,
> 0x4cf0d152 <handle_intel+146>, 0xbfffe7cf, 0x0, 0x96dfd800,
> 0xbfffe7a0, 0x8, 0xbfffe7a3, 0x80487c0, 0x80487b4, 0xf0b2ff,
> 0x8048243, 0xca0000, 0x4d01cff4, 0x0, 0x0, 0xbfffe818, 0x80486c7
> <main+62>, 0xbfffe7e4, 0x8049abc, 0x1, 0x80482cd <_init+41>,
> 0x4d01b1b4, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa,
> 0x80486e0 <__libc_csu_init>, 0x0, 0x0, 0x4ce896b3
> <__libc_start_main+243>, 0x1, 0xbfffe8b4, 0xbfffe8bc, 0x4ce6cfc4}^M
> (gdb) PASS: gdb.trace/backtrace.exp: traceframe 4: tdump on frame 1
> 
> gdb:
> 
> 2013-06-27  Pedro Alves  <pedro@codesourcery.com>
> 	    Yao Qi  <yao@codesourcery.com>
> 
> 	* tracepoint.c (trace_dump_command): Select the current frame.
> 
> gdb/testsuite:
> 
> 2013-06-27  Yao Qi  <yao@codesourcery.com>
> 
> 	* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Test command
> 	'tdump' on stack frame 0 and 1 respectively.
> ---
>  gdb/testsuite/gdb.trace/backtrace.exp |   19 +++++++++++++++++++
>  gdb/tracepoint.c                      |    6 ++++++
>  2 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.trace/backtrace.exp b/gdb/testsuite/gdb.trace/backtrace.exp
> index e40428f..6f32f2a 100644
> --- a/gdb/testsuite/gdb.trace/backtrace.exp
> +++ b/gdb/testsuite/gdb.trace/backtrace.exp
> @@ -211,6 +211,7 @@ proc gdb_backtrace_tdp_3 { msg } {
>  
>  proc gdb_backtrace_tdp_4 { msg depth traceframe } {
>      global gdb_prompt
> +    global decimal hex
>  
>      with_test_prefix "traceframe $traceframe" {
>  	# We are in a trace frame at which we collected all registers,
> @@ -230,6 +231,24 @@ proc gdb_backtrace_tdp_4 { msg depth traceframe } {
>  		fail "$msg (fewer than $depth stack frames found)"
>  	    }
>  	}
> +
> +	# Make sure no output like "0x0 <repeats 2 times>" confuses
> +	# the matching below.
> +	gdb_test_no_output "set print repeats 64" ""
> +
> +	# Match the output of command 'tdump' like '0xbfffe810' or
> +	# '0x4ce55a39 <_dl_lookup_symbol_x+265>'.
> +	gdb_test "tdump" \
> +	    "Data collected at tracepoint $decimal, trace frame $decimal:.* = \\{($hex, |$hex <.*>, ){63}($hex|$hex <.*>)\\}" \
> +	    "tdump on frame 0"
> +
> +	gdb_test "up" ".*" ""
> +
> +	# Test command 'tdump' still work properly when the selected
> +	# frame is not the current frame.
> +	gdb_test "tdump" \
> +	    "Data collected at tracepoint $decimal, trace frame $decimal:.* = \\{($hex, |$hex <.*>, ){63}($hex|$hex <.*>)\\}" \
> +	    "tdump on frame 1"

IMO, this testing method isn't as robust or easy to understand/debug as it
could be.  IMO, the best would be to store the output of tdump while looking
at frame #0, and then compare that to the output of tdump while looking
at frame #1.  It should come out the same.  See gdb.base/gcore.exp,
capture_command_output, etc..  WDYT?

-- 
Pedro Alves