From: Pedro Alves <palves@redhat.com>
To: "Gustavo, Luis" <luis_gustavo@mentor.com>
Cc: Stan Shebs <stanshebs@earthlink.net>, gdb-patches@sourceware.org
Subject: Re: [rfc target-side break conditions 5/5 v2] GDBServer-side changes
Date: Thu, 23 Feb 2012 17:25:00 -0000 [thread overview]
Message-ID: <4F466A38.8080109@redhat.com> (raw)
In-Reply-To: <4F450705.2010407@mentor.com>
Hi Luis,
On 02/22/2012 03:17 PM, Luis Gustavo wrote:
> On 02/09/2012 10:32 AM, Pedro Alves wrote:
>>> Index: gdb/gdb/gdbserver/server.c
>>> ===================================================================
>>> --- gdb.orig/gdb/gdbserver/server.c 2012-02-08 15:57:07.399075002 -0200
>>> +++ gdb/gdb/gdbserver/server.c 2012-02-08 15:57:33.139074999 -0200
>>> @@ -1621,6 +1621,9 @@ handle_query (char *own_buf, int packet_
>>> strcat (own_buf, ";tracenz+");
>>> }
>>>
>>> + /* Support target-side breakpoint conditions. */
>>> + strcat (own_buf, ";ConditionalBreakpoints+");
>>
>> I still think it's a shame this doesn't mean all Z packets
>> understand target side conditionals...
>
> This probably means all Z packets, but only breakpoints are being implemented now on both gdbserver's and gdb's side.
There's no probably :-). GDB will need to be able to tell.
Either it does, or it doesn't. If watchpoints aren't supported now, we'll need
a new qSupported bit latter when we support them. (*) No biggie, but the
documentation should be clear (may it already is though, haven't checked
for that).
(*) I thought about it a bit, and I had a moment of "damn, this isn't
going to work", thinking about the fact that we're assuming the stubs
must ignore Z packets for the same addresses, and that with watchpoints
that might not work, given that the remote side does reference counting
of resources, to handle overlapping watchpoints. Then I remembered that
GDB will never send exact duplicates of watchpoints, so it can send
1 watchpoint location for ADDR1;LEN1 and another for ADDR1;LEN2, but never
two for ADDR1;LEN1 (assuming same type). So we're good, and supporting
this for watchpoints shouldn't be hard.
>
>>
>>
>>> +static void
>>> +process_point_options (CORE_ADDR point_addr, char **packet)
>>> +{
>>> + char *dataptr = *packet;
>>> +
>>> + while (dataptr[0] == ';')
>>> + {
>>> + dataptr++;
>>> +
>>> + if (!strncmp (dataptr, "conditions=", strlen ("conditions=")))
>>
>> strncmp's return is not a boolean. Please write as
>>
>> if (strncmp (dataptr, "conditions=", strlen ("conditions=")) == 0)
>
> Fixed.
>
>>
>>> + {
>>> + /* We have conditions to parse. */
>>> + dataptr += strlen ("conditions=");
>>> +
>>> + /* Insert conditions. */
>>> + do
>>> + {
>>> + add_breakpoint_condition (point_addr,&dataptr);
>>> + } while (*dataptr == 'X');
>>> + }
>>> + }
>>
>> Should we silently ignore unknown options, or error? If the former,
>> then you should skip to the next `;' and go from there. If the latter,
>> well, and error is missing. :-)
>
> Silently ignore. I thought further about the "conditions" marker and i decided to drop it. We may want to pass more attributes in the future, and these markers will be an overhead and will possibly get in the way.
>
> I'm passing plain expressions now, with the first char identifying the action. This is in synch with how tracepoint actions/attributes are passed down to the target.
>
> This also makes it easier to ignore unknown tokens, which in turn allows people to easily extend the list of attributes in Z packets in the future.
>
> What do you think?
Hmm, thinking more, I don't think GDB should ever send tokens the
stub didn't report support for in qSupported, so in practice it
doesn't matter that much either way, but in any case:
> +/* Process options coming from Z packets for *point at address
> + POINT_ADDR. PACKET is the packet buffer. *PACKET is updated
> + to point to the first char after the last processed option. */
> +
> +static void
> +process_point_options (CORE_ADDR point_addr, char **packet)
> +{
> + char *dataptr = *packet;
> +
> + /* Check if data has the correct format. */
> + if (*dataptr != ';')
> + return;
> +
> + dataptr++;
> +
> + while (*dataptr)
> + {
> + switch (*dataptr)
> + {
> + case 'X':
> + /* Conditional expression. */
> + fprintf (stderr, "Found breakpoint condition.\n");
> + add_breakpoint_condition (point_addr, &dataptr);
> + break;
> + default:
> + /* Unrecognized token, just skip it. */
> + fprintf (stderr, "Unknown token %c, ignoring.\n",
> + *dataptr);
> + dataptr++;
That's not the proper way to skip an unknown token. You need to skip
until some known marker (`;' or `,' or some such).
> + }
> + }
> + *packet = dataptr;
> +}
Everything else looked good to me now. Thanks.
--
Pedro Alves
next prev parent reply other threads:[~2012-02-23 16:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 20:34 Luis Gustavo
2012-02-07 22:14 ` Stan Shebs
2012-02-08 23:14 ` Luis Gustavo
2012-02-09 12:33 ` Pedro Alves
2012-02-22 15:25 ` Luis Gustavo
2012-02-23 17:25 ` Pedro Alves [this message]
2012-02-24 12:19 ` Luis Gustavo
2012-02-24 12:52 ` Pedro Alves
2012-02-24 12:59 ` Luis Gustavo
2012-02-24 13:01 ` Pedro Alves
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=4F466A38.8080109@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis_gustavo@mentor.com \
--cc=stanshebs@earthlink.net \
/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