Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Jim Blandy <jimb@red-bean.com>]

On 1/15/06, Robert Dewar <dewar@adacore.com> wrote:
> I strongly object to removing the menus which are very convenient to
> use. No proposal here comes close to being as convenient. For the
> overriding case, here is typical usage:

Your example doesn't correspond to the case we're discussing.

In your example (if I'm guessing my way through Ada and your .gdbinit
user-defined functions properly), there is an ambiguity in what
"parent" refers to; the menu lets you select one.

But the case being discussed in this thread is menus that appear in
response to a location specified by a filename and line number.  It's
not clear that the kind of legitimate ambiguity you're concerned about
is present here.

When a function has been inlined, it's odd for users to demand to be
able to set breakpoints on one inlined instance but not another.  You
can't set a breakpoint on a function conditional on it having been
called from a certain place; why would users suddenly require that
functionality just because the compiler decided to optimize the code
in a certain way?

In-charge and not-in-charge constructors are a similar situation. 
There's nothing in the semantics of the source language that ever
suggests that there are two separate reifications of the single block
of code the user wrote.  This differs from instantiations of generics,
which (if I understand right) are things that the user actually did
ask for.  The two constructor instances don't behave differently, as
far as the source level in concerned.  Separating the two is purely an
implementation strategy, and should be hidden from the user when
reasonable.

In cases where the same code has been #included twice, I think there's
more of a case that users might want to choose one or the other, since
it is indeed explicit in the source code that this particular source
line is going to contribute twice to the translation unit.  But even
here, setting the breakpoint in both places would be a clear
improvement over what we do now: choose one #inclusion randomly.

(The last time we discussed this, Michael Chastain pointed out that
you actually *do* want to choose a specific constructor instance when
you're disassembling.  But we're talking about breakpoints here; the
decision just needs to be made at the right place, so we can do one
thing for 'break' and a different thing for 'disass'.)