This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Jim Blandy wrote:

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.


OK, understood.

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?


I agree with this for the caser of inlined procedures, and I don't think it is
even necessary to have the possibility of setting breakpoints on an instance
by instance basis


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.


I agree

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.


Indeed, one random instance is for suer wrong

(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'.)


There is one more case, related to the #include case, which is generic templates in Ada, and here
too I think you want the possibility of setting a breakpoint in specific instances.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]