Re: [PATCH 2/6] Introduce `pre_expanded sals'

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> I disagree with that generalization.  E.g., next, you'll want that
Pedro> a break on "C::C" (with C being a C++ class) sets a location on each
Pedro> contructor overload).

Yes.

Pedro> And then breakpoints set in in-charge and
Pedro> not-in-charge versions of each of those constructors ends up at the
Pedro> same hierarchycal level under that super breakpoint.  If the user wants
Pedro> to disable one of the (source level) overloads, he now needs to know
Pedro> about the multiple locations of that specific overload.

Sure, because `break C::C' is ambiguous.

In some particular subset of such cases, gdb recognizes the ambiguity
and presents a menu to the user.  In other cases gdb either does
something random (it picks a location according to a hidden algorithm)
or sets a breakpoint on all locations (the `break file.c:73' inline case
-- but even that seems to involve some mystery, since from what I see it
seems to check for matching enclosing function names).

I don't think this is a very good state of affairs.

Pedro> Another argument, is that frontends and users using them aren't
Pedro> expecting that a single breakpoint is represented by more than
Pedro> one visual "point", circle next to the sources, or something like
Pedro> that.  Hitting F8 to toggle a breakpoint's enablement changing
Pedro> some other location source "point" enablement in the sources not
Pedro> currently visible seems to break some abstration to me.  I think
Pedro> such design change needs to consider all these issues (and be
Pedro> experimented with some frontend).

I think we should not worry excessively about CLI users adapting.

I see what you mean about MI, but in practice I think MI clients
generally set `file:line' breakpoints anyway.

In any case historical arguments don't apply to the SystemTap case,
which is new.  No existing front end will request probe points.

Tom