Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Stan Shebs <stan@codesourcery.com>
Subject: Re: [PATCH] Handle errors in tracepoint target agent
Date: Thu, 25 Mar 2010 10:27:00 -0000	[thread overview]
Message-ID: <201003251027.14862.pedro@codesourcery.com> (raw)
In-Reply-To: <4BAAB2E9.7020708@codesourcery.com>

On Thursday 25 March 2010 00:48:41, Stan Shebs wrote:

> But before committing, I want to get feedback on what to do about a 
> protocol mistake I made with this one; the descriptive string is 
> included verbatim in the status packet, which means that it can't have 
> colons embedded, and probably other characters.  There are a couple ways 
> to fix - encode the string in hex, or add a length prefix.

IMO, we should hex encode the string, like we do for other
protocol transfered user visible strings.

> The problem is that this feature has been in Ericsson's hands for awhile, bolted 
> into their application already I think, and so there is a compatibility 
> issue.  We do have the list of strings that their agent returns, and we 
> could say for instance that a leading numeric digit is assumed to 
> indicate a length field, otherwise it's handled verbatim.  On the flip 
> side, this all is getting rather arcane, so maybe I'm worrying too much 
> about it.  What do people think?

IIRC, we've had similar issues before, and the decision tends to be to
fix the mistake in the FSF version, and worry about backwards compatility
in the local versions (Ericsson's gdb, in this case).  I think this should
work: try to hex2bin the string, and if that doesn't consume the whole
buffer up to ':', then we have a non-hex encoded string.  We're still
adding features for Ericsson, so with time there's good chance the
old version will disappear from their systems.

> +         if (ts->stopping_tracepoint)
> +           printf_filtered (_("Trace stopped by an error (%s, tracepoint %d).\n"),
> +                            (ts->error_desc ? ts->error_desc : ""),

This doesn't assume error_desc is always non-NULL,

> !   fprintf (fp, "status %c;%s%s%s:%x",
>            (ts->running ? '1' : '0'),
> !          stop_reason_names[ts->stop_reason],
> !          (ts->stop_reason == tracepoint_error ? ":" : ""),
> !          (ts->stop_reason == tracepoint_error ? ts->error_desc : ""),

But this seems to.  The parsing code (below) seems to cope with a non-existent
description, and leaves the field NULL in that case, so it seems that
the "status %c..." print above should cope with it as well.

> +       else if (strncmp (p, stop_reason_names[tracepoint_error], p1 - p) == 0)
> +       {
> +         p2 = strchr (++p1, ':');
> +         if (p2 != p1)
> +           {
> +             ts->error_desc = (char *) xmalloc (p2 - p1 + 1);
> +             memcpy (ts->error_desc, p1, p2 - p1);
> +             ts->error_desc[p2 - p1] = '\0';


>   void
> + write_error_trace_file ()
                          ^^^^

"(void)" please.

> +   /* Dump the size of the R (register) blocks in traceframes.  */
> +   snprintf (spbuf, sizeof spbuf, "R %x\n", 500 /* FIXME get from arch */);
> +   write (fd, spbuf, strlen (spbuf));

FIXME?  If not important, or if this just need to be as big enough
to cope with all supported archs, then we should drop the FIXME note,
and explain that instead.

> +   /* Dump tracepoint definitions, in syntax similar to that used
> +      for reconnection uploads.  */
> +   snprintf (spbuf, sizeof spbuf, "tp T1:%lx:E:0:0\n",
> +           (long) &write_basic_trace_file);

This will fail to compile with "warning: cast to integer from pointer
of different size" on some archs.

> +   /* Write end of tracebuffer marker.  */
> +   *((short *) trptr) = 0;
> +   trptr += sizeof (short);
> +   *((int *) trptr) = 0;
> +   trptr += sizeof (int);

Please don't add code like this.  These casts and
dereferences tend to work on x86, because that arch can
write to unaligned addresses.  Most others can't.  This should
do memset instead.  Assuming short is 2 bytes and int is 4
isn't supper portable either, but it will be a while longer
to trip on that.

>   # Make sure we are starting fresh.
>   remote_exec build {sh -xc rm\ -f\ basic.tf}
> + remote_exec build {sh -xc rm\ -f\ error.tf}

These should be doing "remote_file host delete ${filefoo}"
instead.  As is won't work with remote host testing, where
the .tf files are produced on host, not on build.

-- 
Pedro Alves


  parent reply	other threads:[~2010-03-25 10:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-25  0:48 Stan Shebs
2010-03-25  4:18 ` Eli Zaretskii
2010-03-25 10:27 ` Pedro Alves [this message]
2010-03-25 22:30   ` Stan Shebs
2010-03-25 22:42     ` Pedro Alves
2010-03-25 23:06       ` Stan Shebs

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=201003251027.14862.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --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