This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] Select the current frame in command tdump.
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 29 Jul 2013 16:44:36 +0100
- Subject: Re: [PATCH 3/3] Select the current frame in command tdump.
- References: <1372341726-5485-1-git-send-email-yao at codesourcery dot com> <1372341726-5485-4-git-send-email-yao at codesourcery 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