[PATCH 0/2] info breakpoints improvements

Pedro Alves pedro@palves.net
Tue May 24 13:50:01 GMT 2022


On 2022-05-24 14:43, Eli Zaretskii wrote:
>> Date: Tue, 24 May 2022 14:29:27 +0100
>> Cc: luis.machado@arm.com, gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>> On 2022-05-24 14:20, Eli Zaretskii wrote:
>>>> Date: Tue, 24 May 2022 11:02:07 +0100
>>>> From: Pedro Alves <pedro@palves.net>
>>>>
>>>> Note how breakpoint 4 is disabled, but since all the locations are enabled, the "n" doesn't stand out all that much.
>>>
>>> I'm confused: what is the meaning of having a breakpoint disabled,
>>> while all of its locations are enabled?  Under which conditions will
>>> such a breakpoint break?
>>>
>>
>> A location only breaks if it is enabled, _and_ its parent is enabled, so never.
> 
> That's what I thought.  But then why not "propagate" the "n" of the
> disabled breakpoint to all of its locations?  

Because then when you re-enable the parent breakpoint, you'd have lost the enabled/disabled
state of the individual locations.  It's like, if you turn off the mains switch in your
home, the individual light switches in each room stay in their positions.  And you can
flip on/off the individual switches before turning on the mains too.

That way
> 
>   (gdb) info break 4.10
> 
> will show the truth, no?

You can't "info break" an individual location.

> 
> I also wonder whether we should display something special on the
> "header row" instead of "y" or "n" when some of the locations are
> enabled and others aren't.  How about "p" (for "partial") or maybe
> "y/n"?
> 

That may be useful, yes.


More information about the Gdb-patches mailing list