From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: Marc Khouzam <marc.khouzam@ericsson.com>,
"'dje@google.com'" <dje@google.com>,
"'gdb-patches@sourceware.org'"
<gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] new tracepoint downloaded MI notification.
Date: Thu, 29 Nov 2012 16:00:00 -0000 [thread overview]
Message-ID: <50B78675.4010505@redhat.com> (raw)
In-Reply-To: <50B7834B.3060508@codesourcery.com>
On 11/29/2012 03:46 PM, Yao Qi wrote:
> On 11/23/2012 02:32 AM, Pedro Alves wrote:
>> What about the case of connecting to a target that is tracing, after
>> disconnected tracing? Do we already tell the frontend somehow which
>> tracepoints are active on the target? Should tracepoints have an
>> "installed on target" field?
>>
>> Yao Qi wrote:
>>> >On 11/01/2012 03:09 AM, Marc Khouzam wrote:
>>>> >>Now that GDB pushes new tracepoints to the target immediately, that
>>>> >>use-case may not apply, but I wonder if there are other situations
>>>> >>where some tracepoints will be on the target and other will not?
>>> >
>>> >Yes, the pending tracepoints won't be downloaded after tracing is started until they are resolved. The notification is required for this case.
>> Ok. If the answer to my question above is yes, it might be this
>> notification ends up unnecessary in favor of a generic
>> =breakpoint-modified.
>
> Pedro, to make sure I don't misread your comments, I'd like to ask are you suggesting that we can add an 'installed on target' field for tracepoint in '=breakpoint-modified' notification?
Well, sort of, but by side effect, since =breakpoint-modified includes all
the fields of a breakpoint/tracepoint.
Say you've set up a disconnected tracing session, and then disconnect.
Later, you start a new clean gdb session, create a new tracepoint (never
downloaded/installed on the target), and reconnect. At this point, GDB will fetch
the target's tracepoint list, and sync it with GDB's. The frontend gets
a =breakpoint-created for each of those uploaded tracepoints, but it has
no clue why they were created / their installed status.
You end up with some tracepoints that are installed, and some that aren't
in GDB's list. Does the frontend know this today by some means I'm missing?
If not, does fixing this mean adding an "installed" property to
breakpoints/tracepoints? Say we added your new notification, and then fixed the
above as I'm suggesting. At that point, this new tracepoint downloaded
notification ends up being redundant.
So I'm trying to get us to think with a broad perspective around
the "installed on target" frontend needs.
--
Pedro Alves
next prev parent reply other threads:[~2012-11-29 16:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 0:49 [RFC 0/2] Two new MI notifications Yao Qi
2012-09-28 0:49 ` [PATCH 2/2] new tracepoint downloaded MI notification Yao Qi
2012-09-28 7:37 ` Eli Zaretskii
2012-09-28 17:44 ` Pedro Alves
2012-09-28 17:47 ` Pedro Alves
2012-09-29 14:13 ` Yao Qi
2012-10-09 8:12 ` Yao Qi
2012-10-31 17:59 ` Pedro Alves
2012-10-31 19:20 ` Doug Evans
2012-11-01 0:34 ` Yao Qi
2012-11-02 15:46 ` Pedro Alves
2012-11-02 15:50 ` Pedro Alves
2012-10-18 1:16 ` Yao Qi
2012-10-18 1:28 ` Yao Qi
2012-10-30 7:07 ` [ping]: " Yao Qi
2012-10-30 17:22 ` Eli Zaretskii
2012-10-18 4:43 ` Eli Zaretskii
2012-10-18 19:54 ` Tom Tromey
2012-09-28 17:44 ` Pedro Alves
2012-09-28 18:27 ` Tom Tromey
2012-09-28 18:29 ` Tom Tromey
2012-10-15 18:03 ` dje
2012-10-31 18:03 ` Pedro Alves
2012-10-31 19:10 ` Marc Khouzam
2012-11-01 0:22 ` Yao Qi
2012-11-22 18:33 ` Pedro Alves
2012-11-29 15:47 ` Yao Qi
2012-11-29 16:00 ` Pedro Alves [this message]
2012-11-29 19:34 ` Marc Khouzam
2012-09-28 0:49 ` [PATCH 1/2] new memory-changed " Yao Qi
2012-09-28 7:36 ` Eli Zaretskii
2012-09-28 7:58 ` Yao Qi
2012-09-28 8:25 ` Eli Zaretskii
2012-09-28 17:17 ` Tom Tromey
2012-09-29 1:18 ` Yao Qi
2012-10-09 7:44 ` Yao Qi
2012-10-15 17:58 ` dje
2012-10-15 19:07 ` Tom Tromey
2012-10-16 7:12 ` Yao Qi
2012-10-15 19:03 ` Tom Tromey
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=50B78675.4010505@redhat.com \
--to=palves@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=marc.khouzam@ericsson.com \
--cc=yao@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