Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Abid, Hafiz" <hafiz_abid@mentor.com>
Cc: gdb-patches@sourceware.org, stan@codesourcery.com
Subject: Re: [patch] Change trace buffer size
Date: Wed, 27 Feb 2013 16:39:00 -0000	[thread overview]
Message-ID: <512E36AB.90200@redhat.com> (raw)
In-Reply-To: <1361211216.2217.2@abidh-ubunto1104>

On 02/18/2013 06:13 PM, Abid, Hafiz wrote:
>
> Hi All, This patch adds support for QTBuffer:size in gdbserver
> and adds commands in gdb to use this packet to change the
> trace buffer size.  The default value of the buffer size in
> gdb is -1 which means that target will use whatever size it likes.
>
> I notice that there are some tests that are using "maint packet"
> to send QTBuffer:size. I was not sure what to do with them so
> I have left them alone. If reviewers suggest, I can update/remove them.

Yeah, http://sourceware.org/ml/gdb-patches/2012-02/msg00303.html

So, previously, because gdbserver didn't implement this, some
tests were skipped.  What about after the patch?

On 02/18/2013 06:13 PM, Abid, Hafiz wrote:
> +@item QTBuffer:size:@var{size}
> +This packet directs the target to make the trace buffer be of size
> +@var{size} if possible.
> +

This misses explaining the "-1" magic.

> +static int trace_buffer_size;

Should be a ssize_t, or LONGEST.  The latter is probably
better/simpler in this case.

> +init_trace_buffer (int bufsize)

This "int" too.

>  {
> -  trace_buffer_lo = buf;
> +  trace_buffer_size = bufsize;
> +
> +  /* If we already have a trace buffer, try realloc'ing.  */
> +  if (trace_buffer_lo)
> +    trace_buffer_lo = xrealloc (trace_buffer_lo, bufsize);
> +  else
> +    trace_buffer_lo = xmalloc (bufsize);

xrealloc(NULL, bufsize) is equivalent to xmalloc(bufsize),
so the if is unnecessary.  Write only:

    trace_buffer_lo = xrealloc (trace_buffer_lo, bufsize);


> +static void
> +remote_set_trace_buffer_size (LONGEST val)
> +{
> +  struct remote_state *rs = get_remote_state ();
> +  char *p, *reply;
> +
> +  sprintf (rs->buf, "QTBuffer:size:");
> +  p = rs->buf + strlen (rs->buf);
> +  p += hexnumstr (p, (ULONGEST) val);
> +  putpkt (rs->buf);

This should send -1 really as literal "-1",
instead of ffff..ff, which depends on the size
of ULONGEST, which may not be the same as the target's.
IOW, it's host dependent.

> +  reply = remote_get_noisy_reply (&target_buf, &target_buf_size);

We shouldn't be adding more uses of target_buf, target_buf_size.
Use:
  remote_get_noisy_reply (&rs->buf, &rs->buf_size);

and:

  if (*rs->buf == '\0')

but, OTOH, new packets should really be using packet_ok.

This:

>  static int
>  remote_set_trace_notes (char *user, char *notes, char *stop_notes)
>  {
> @@ -11050,6 +11067,7 @@ remote_set_trace_notes (char *user, char *notes, char *stop_notes)
>    char *buf = rs->buf;
>    char *endbuf = rs->buf + get_remote_packet_size ();
>    int nbytes;
> +  int any = 0;
>
>    buf += xsnprintf (buf, endbuf - buf, "QTNotes:");
>    if (user)
> @@ -11058,6 +11076,7 @@ remote_set_trace_notes (char *user, char *notes, char *stop_notes)
>        nbytes = bin2hex (user, buf, 0);
>        buf += 2 * nbytes;
>        *buf++ = ';';
> +      any = 1;
>      }
>    if (notes)
>      {
> @@ -11065,6 +11084,7 @@ remote_set_trace_notes (char *user, char *notes, char *stop_notes)
>        nbytes = bin2hex (notes, buf, 0);
>        buf += 2 * nbytes;
>        *buf++ = ';';
> +      any = 1;
>      }
>    if (stop_notes)
>      {
> @@ -11072,7 +11092,10 @@ remote_set_trace_notes (char *user, char *notes, char *stop_notes)
>        nbytes = bin2hex (stop_notes, buf, 0);
>        buf += 2 * nbytes;
>        *buf++ = ';';
> +      any = 1;
>      }
> +    if (any == 0)
> +      return 0;
>    /* Ensure the buffer is terminated.  */
>    *buf = '\0';

looks unrelated to trace buffer size.  Please split it
into a separate patch.

> +set BUFFER_SIZE 1024
> +gdb_test_no_output "set trace-buffer-size $BUFFER_SIZE" "Set Trace Buffer Size"
> +gdb_test "show trace-buffer-size $BUFFER_SIZE" "Requested size of trace buffer is $BUFFER_SIZE.*" \
> +"Show Trace Buffer Size"
> +

This test doesn't seem to really test that much.  I wonder if
you have ideas on expanding it?

> +/* This variable is the requested trace buffer size, or -1 to indicate
> +   that we don't care and leave it up to the target to set a size.  */
> +
> +static int trace_buffer_size = -1;

Should probably be a LONGEST too.  There's to reason to
actually limit to 31-bits, right?

> +  add_setshow_zinteger_cmd ("trace-buffer-size", no_class,
> +			    &trace_buffer_size, _("\

Oh, I see...  add_setshow_zinteger_cmd works with int...

-- 
Pedro Alves


  parent reply	other threads:[~2013-02-27 16:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 18:13 Abid, Hafiz
2013-02-18 20:00 ` Eli Zaretskii
2013-02-19  2:53 ` Yao Qi
2013-02-27 16:55   ` Pedro Alves
2013-02-28  0:52     ` Yao Qi
2013-02-27 16:39 ` Pedro Alves [this message]
2013-03-01 17:07   ` [patch] Change trace buffer size(v2) Abid, Hafiz
2013-03-01 18:13     ` zinteger setshow commands broken Pedro Alves
2013-03-04 10:10       ` Abid, Hafiz
2013-03-04 10:16         ` Yao Qi
2013-03-04 10:28         ` Pedro Alves
2013-03-01 20:02     ` [patch] Change trace buffer size(v2) Pedro Alves
2013-03-04 19:03       ` [patch] Change trace buffer size(v3) Abid, Hafiz
2013-03-04 20:43         ` Pedro Alves
2013-03-05 14:12           ` [patch] Change trace buffer size(v4) Abid, Hafiz
2013-03-05 20:13             ` Pedro Alves
2013-03-08 11:30               ` [patch] Change trace buffer size(v5) Abid, Hafiz
2013-03-08 14:09                 ` Eli Zaretskii
2013-03-08 14:27                   ` Abid, Hafiz
2013-03-08 14:28                 ` Pedro Alves
2013-03-08 14:52                 ` Yao Qi
2013-03-08 15:15                   ` Abid, Hafiz
2013-03-08 15:27                     ` Yao Qi
2013-05-02 17:31                     ` Pedro Alves
2013-05-03 11:38                       ` Abid, Hafiz
2013-05-03 14:05                         ` Pedro Alves
2013-05-03 15:08                           ` Abid, Hafiz
2013-05-03 15:26                             ` Pedro Alves
2013-03-09  2:06                 ` Joel Brobecker
2013-03-09  8:27                   ` Eli Zaretskii
2013-03-09 10:20                     ` Abid, Hafiz
2013-03-09 10:39                       ` Abid, Hafiz
2013-03-09 11:11                         ` Eli Zaretskii
2013-03-09 11:07                       ` Eli Zaretskii
2013-03-11 18:33                         ` Tom Tromey
2013-03-11 19:44                           ` Eli Zaretskii

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=512E36AB.90200@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hafiz_abid@mentor.com \
    --cc=stan@codesourcery.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