From: Pedro Alves <palves@redhat.com>
To: "Abid, Hafiz" <hafiz_abid@mentor.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] circ.exp
Date: Wed, 17 Apr 2013 20:33:00 -0000 [thread overview]
Message-ID: <516EC437.5060400@redhat.com> (raw)
In-Reply-To: <1366135406.4863.1@abidh-ubunto1104>
On 04/16/2013 07:03 PM, Abid, Hafiz wrote:
> Thanks for the review and explnation about the circular behavior.
>
>> It'd have been useful if you had pointed out what were the issues.
>> You must have come to the conclusion to you were going to refactor
>> the code _after_ you've analyzed them.
> Here are the problems that I observed.
Thanks, that's very useful.
> 3) When buffer is small and we can not have all 10 frames in it, it was testing
> for "tfind 9" which tries to find the 10th frame which is never there due to small
> buffer size.
> I may be wrong but I think it should rather test for "tfind tracepoint
> 9" which will give it a frame related to tracepoint 9.
How interesting. The trace frame number is a detail of the
target, actually. There's nothing in GDB (IIRC) that expects
the first traceframe to be traceframe number 1. When you do
"tfind 4", that asks the target to select traceframe 4 -- the 4
is sent to the target. It must have been that the original target that
supported tracepoints, the one this test was written for originally years
and years ago recorded the trace frame number in the traceframe itself.
But that's not how GDBserver works. GDBserver counts traceframes from the
first recorded traceframe instead:
/* Given a traceframe number NUM, find the NUMth traceframe in the
buffer. */
static struct traceframe *
find_traceframe (int num)
{
struct traceframe *tframe;
int tfnum = 0;
for (tframe = FIRST_TRACEFRAME ();
tframe->tpnum != 0;
tframe = NEXT_TRACEFRAME (tframe))
{
if (tfnum == num)
return tframe;
++tfnum;
}
We should update the comments and test messages too then:
# 1) frame zero will be overwritten and therefore unavailable
# 2) the earliest frame in the buffer will be other-than-zero
# 3) frame nine will be available (unlike "small buffer" case).
s/other-than-zero/for a tracepoint other than 1/
s/frame nine/the frame for tracepoint 9/
gdb_test \
"tfind tracepoint 9" ".*Found trace frame $decimal, tracepoint 9.*" \
"find frame nine"
s/frame /frame for tracepoint/
etc.
Then might as well make all similar tfinds in the non-circular cases
use "tfind tracepoint" too for consistency.
> 4) Many tests were expecting current stack frame to be printed as result of
> tfind command e.g. "#0 func9 .*". But this only happens when traceframe_number
> is -1. In the following code, old_frame_id equal to current frame id unless
> traceframe_number < 0.
>
I'm confused. Does the tfind in question switch to a different
frame or not?
> if (!(type == tfind_number && num == -1)
> && (has_stack_frames () || traceframe_number >= 0))
> old_frame_id = get_frame_id (get_current_frame ());
> ...
> if (frame_id_eq (old_frame_id,
> get_frame_id (get_current_frame ())))
> print_what = SRC_LINE;
> else
> print_what = SRC_AND_LOC;
>> As a follow up, it'd be nice to use gdb features/commands instead
>> of manually sending packets to probe support. E.g, use tstatus to
>> check for support:
> I thought we meant to test both through commands and packets. But if you
> feel that we should only use commands then I can do that in next version.
I feel that we should only use commands. There's no good reason
to limit the test to the remote protocol. As soon as someone implements
tracepoints on some other target (native or something else), we'd
need to stop using direct RSP packets anyway. The test used a direct
packet because there was no user-accessible support for changing the
trace buffer size. It was just a hack.
Thanks. This is looking great.
BTW, I realized this is the existing style in the test, but
these "if (...) then return 1" sprinkled around are really
unnecessary.
+ if [setup_tracepoints] then { return 1 }
+ if [gdb_test "break end" "Breakpoint $decimal.*" \
+ "breakpoint at end"] then { return 1 }
+ if [gdb_test "tstart" \
+ "\[\r\n\]*" \
+ "start trace experiment"] then { return 1 }
I'd zap them.
--
Pedro Alves
next prev parent reply other threads:[~2013-04-17 15:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 18:26 Abid, Hafiz
2013-04-11 22:59 ` Abid, Hafiz
2013-04-16 7:52 ` Pedro Alves
2013-04-16 20:53 ` Abid, Hafiz
2013-04-17 20:33 ` Pedro Alves [this message]
2013-04-17 20:54 ` Abid, Hafiz
2013-04-18 10:30 ` Pedro Alves
2013-04-18 11:09 ` Pedro Alves
2013-12-13 17:49 ` [PATCH] "tfind" across unavailable-stack frames Pedro Alves
2013-12-14 6:23 ` Yao Qi
2013-12-16 16:19 ` Pedro Alves
2013-12-17 9:04 ` Yao Qi
2013-12-17 10:09 ` Pedro Alves
2013-12-17 12:39 ` Yao Qi
2013-12-17 20:55 ` Pedro Alves
2013-12-16 8:40 ` Metzger, Markus T
2013-12-16 16:25 ` Pedro Alves
2013-12-16 16:42 ` [PATCH v2] " Pedro Alves
2013-04-19 14:27 ` [patch] circ.exp Abid, Hafiz
2013-04-19 14:28 ` Pedro Alves
2013-05-08 10:12 ` Abid, Hafiz
2013-05-08 15:13 ` Pedro Alves
2013-05-08 16:18 ` Abid, Hafiz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=516EC437.5060400@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=hafiz_abid@mentor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox