Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pmuldoon@redhat.com, gdb@sourceware.org
Subject: Re: Multiple locations and breakpoints confusion.
Date: Wed, 02 May 2018 16:43:00 -0000	[thread overview]
Message-ID: <e8f5d280-8f82-696b-d6aa-87f1f99e5add@redhat.com> (raw)
In-Reply-To: <83po2eow5u.fsf@gnu.org>

On 05/02/2018 05:32 PM, Eli Zaretskii wrote:
>> Cc: pmuldoon@redhat.com, gdb@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Wed, 2 May 2018 17:15:32 +0100
>>
>>> If disabling the parent disables all of its children, why not show all
>>> of the children disabled when the parent is disabled?  IOW, why can't
>>> we make the y/n display use the same logic as the one used when
>>> deciding whether a breakpoint at a particular location is disabled?
>> That loses information, i.e., one can't tell which ones were explicitly
>> disabled, and will be re-enabled.
> 
> Providing this information is not the main purpose of that display.
> The main purpose is to accurately describe the current state of
> affairs.

The current gdb output describes the current state of affairs.
See my other email.

> 
>> Really can't see why that's better and more desirable.
> 
> I guess we disagree, then.
> 

I agree we disagree.  :-)

> My problem with all your alternative suggestions is that they all are
> riddles, to some extent: the interpretation of "y.n", "y(n)", etc. is
> impossible without reading the manual.  Which is a regression of
> sorts, because the simple "y" or "n" display is immediately
> understandable by just looking at it.

Note it was not "y(n)" that was suggested, but "(y)", as in,
"location is explicitly enabled, but not actually active".

But if you ask me, the current output is immediately
understandable.  I'd go for updating the manual.

> 
>> And it'd still be confusing to someone -- "why is it that when I
>> disable the parent, all its locations show as disabled, but when I
>> enable the parent, only some locations show as enabled, why not
>> all?" would then be a legitimate question.
> 
> And the answer is that the user actually asked for that by her
> actions.  So I have no problem with this difficulty.

The current output is what the user gets too as consequence
of her actions, so I don't see why that serves as argument.
Just different expectations.

Thanks,
Pedro Alves


  reply	other threads:[~2018-05-02 16:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-01  8:15 Phil Muldoon
2018-05-01 19:32 ` Pedro Alves
2018-05-02 15:13   ` Eli Zaretskii
2018-05-02 16:15     ` Pedro Alves
2018-05-02 16:27       ` Pedro Alves
2018-05-02 16:42         ` Keith Seitz
2018-05-02 16:33       ` Eli Zaretskii
2018-05-02 16:43         ` Pedro Alves [this message]
2018-05-02 16:49           ` Joel Brobecker
2018-05-02 18:18             ` Phil Muldoon
2018-05-02 18:42               ` 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=e8f5d280-8f82-696b-d6aa-87f1f99e5add@redhat.com \
    --to=palves@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=pmuldoon@redhat.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