From: Stan Shebs <stan@codesourcery.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: Stan Shebs <stan@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: tracing broken if target doesn't do disconnected tracing
Date: Thu, 08 Apr 2010 19:10:00 -0000 [thread overview]
Message-ID: <4BBE2A19.3010604@codesourcery.com> (raw)
In-Reply-To: <201004081932.31774.pedro@codesourcery.com>
Pedro Alves wrote:
> On Thursday 08 April 2010 19:18:40, Stan Shebs wrote:
>
>>>> The downside of this design is that if you did want to shut tracing
>>>> down, you have to cancel the detach, do a tstop, then redo the detach.
>>>> It's not crucial perhaps, but it seems a bit pedantic for GDB to have
>>>> the power to choose whether to keep the trace running, but not to
>>>> exercise it, and to insist that you have cancel and type the command
>>>> yourself. Perhaps the crux of the confusion is that this is really a
>>>> three-way choice - trace/detach, tstop/detach, cancel - and a pair of
>>>> yes/no questions is not a good way to model it.
>>>>
>>>>
>>> That's just begging for:
>>>
>>> The downside of your current design is that if you did want to detach
>>> and leave tracing running, you have to cancel the detach, do a "set
>>> disconnected-tracing on", then redo the detach.
>>> It's not crucial perhaps, but it seems a bit pedantic for GDB to have
>>> the power to choose whether to keep the trace running, but not to
>>> exercise it, and to insist that you have cancel and type the command
>>> yourself.
>>>
>>> :-)
>>>
>>>
>> Um, I must be missing the joke, it looks like you cut-n-pasted verbatim?
>>
>
> Your patch only asks the user whether she wants to leave tracing on or
> stop it when "set disconnected-tracing" was on. If it was "off" (the
> user forgot to set it on, as it is off by default), you still have to
> cancel the detach and issue a "set disconnected-tracing on" command.
> The joke was that your words only justify one of the branches in your code,
> and can be used to justify my point in the other branch. Compare the
> first sentences. As is, your patch doesn't expose GDB's power to
> turn disconnected-tracing _on_, only _off_. Following your mental model,
> a user would be much more thankful if gdb offered the ability to turn
> it on, on the spot.
>
>
Ok, I'm with you now. And you're right, they shouldn't be asymmetrical.
Stan
next prev parent reply other threads:[~2010-04-08 19:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-05 0:01 Pedro Alves
2010-04-05 1:08 ` Stan Shebs
2010-04-05 11:04 ` Pedro Alves
2010-04-07 1:34 ` Stan Shebs
2010-04-07 11:40 ` Pedro Alves
2010-04-07 13:33 ` Stan Shebs
2010-04-07 13:47 ` Pedro Alves
2010-04-07 14:07 ` Pedro Alves
2010-04-07 20:21 ` Stan Shebs
2010-04-07 22:06 ` Pedro Alves
2010-04-07 13:35 ` Pedro Alves
2010-04-07 22:04 ` Stan Shebs
2010-04-08 17:25 ` Pedro Alves
2010-04-08 18:19 ` Stan Shebs
2010-04-08 18:32 ` Pedro Alves
2010-04-08 19:10 ` Stan Shebs [this message]
2010-04-09 3:10 ` 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=4BBE2A19.3010604@codesourcery.com \
--to=stan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@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