public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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, 08 May 2013 15:13:00 -0000	[thread overview]
Message-ID: <518A6B97.6070402@redhat.com> (raw)
In-Reply-To: <1368007885.2238.4@abidh-ubunto1104>

On 05/08/2013 11:11 AM, Abid, Hafiz wrote:

> I have used similar code sequence as you described above. But I was wondering if we can
> issue an unsupported call in the 2nd '-re' and then return. That should eliminate the need
> for 'circular_supported'. It also generates an extra pass while we then call unsupported below.

It's really not a biggie either way.  This,

 PASS: check whether circular buffer is supported
 FAIL: check whether circular buffer is supported
 UNSUPPORTED: check whether circular buffer is supported

reads to me as if it's the checking itself that is not supported.
(Very) Pedantically, that 2nd -re means the "check whether circular
buffer is supported" test succeeded.  And from that successful
test, we can infer that the target in fact does not support a
circular buffer.  Contrast with an alternative message
that focuses on what we want to outcome to be, and it'd
make a little more sense to me to issue the unsupported
in the 2nd -re:

 PASS: target buffer is set to circular
 FAIL: target buffer is set to circular
 UNSUPPORTED: target buffer is set to circular

Here FAIL would be an unexpected outcome (caught by gdb_test_multiple
internally, so adorned with "(timeout)" or something else).

Note a separate a variable is still somewhat useful to bail in the case
gdb_test_multiple catches a FAILs internally (timeout, internal error).
We can also check those in the return of gdb_test_multiple, but a
separate variable usually reads nicer, IMO.

> -# return 0 for success, 1 for failure
> -proc run_trace_experiment { pass } {
> -    gdb_run_cmd 
> +# Set a tracepoint on given func.  The tracepoint is set at entry
> +# address and not 'after prologue' address.

I'd find extending the comment with something like:

 ", because we use 'tfind pc func' to find the corresponding trace frame
 afterwards, and that looks for entry address."

to be useful.

> +# Check if changing the trace buffer size is supported.  This step is
> +# repeated twice.  This helps in case if trace buffer size is 100.

s/This helps in case if/The helps in case the/

> +    # Check that we get the total_size and free_size

Missing period.

> +    if { $total_size < 0 } {
>  	return 1
>      }
>  
> -    return 0
> +    if { $free_size < 0 } {
> +	return 1
> +    }
>  }
>  
> -# return 0 for success, 1 for failure
> -proc gdb_trace_circular_tests { } {
> -    if { ![gdb_target_supports_trace] } then { 
> -	unsupported "Current target does not support trace"
> +# Calculate the size of a single frame

Missing period.  Might as well just give it a quick audit
over all strings and add the missing periods.  :-)

> +# Shrink the trace buffer so that it will not hold
> +# all ten trace frames.  Verify that frame for func0 is still
> +# collected, but frame for func9 is not.

s/that frame for/that the frame for/
s/but frame for/but the the frame for/

> +# 1) the first frame will be overwritten and therefore unavailable

Missing period here too.

> +    # Check that teh first frame is actually at func0.

typo: "teh".

The patch is okay with these fixed.  Go ahead and apply it
(but still post the final version).

Thanks,
-- 
Pedro Alves

  reply	other threads:[~2013-05-08 15:13 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
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 [this message]
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=518A6B97.6070402@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).