Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> If we agree that a breakpoint expression (linespec) that gets resolved
Joel> into multiple source locations (slocs) should result in one breakpoint
Joel> per sloc, then we can start working on that.

I am not sure about this plan.  I think it relies on being able to
differentiate breakpoints based on canonical linespecs, but I don't
think it is always possible to construct these.

E.g., consider the case where a linespec resolves to two locations, one
of which does not have debuginfo.  What is the canonical linespec for
the debuginfo-less location?  What if there are three locations and two
of them don't have debuginfo?  I.e., are those two consolidated into a
single breakpoint?  What would its canonical linespec be?  Or if not
consolidated, etc.

Joel> We would rather let the C++ bits to someone else, as we still have
Joel> limited experience with C++ itself.

Sounds good to me.

Joel> We think that this will handle most situations, except the situation
Joel> where new symbols cause extra slocs to appear (typically, a shared
Joel> library gets mapped in memory). We are planing on plugging that hole
Joel> as a followup, which can be made independently, for instance using
Joel> Pedro's idea of introducing an extra level of breakpoint. The exact
Joel> details on how this is going to be done need to be discussed, but,
Joel> in the meantime, our experience with Ada show that the approach
Joel> we are proposing as a first step has been working well for our users.

I would rather start with a comprehensive plan.  My concern about
approaching this piecemeal is that I think dealing with changes in the
inferior will necessitate changes in the basic approach.

Also, I think to get the SystemTap patch set in, I have to solve the
bigger problem anyhow.  That is, I have to start there, at least as I
understand the current situation.


I keep coming back to the "simple" approach I sketched here:

    http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html

I can try to write this up into a fuller proposal if you want.

While looking into this area I made a list of difficulties and
considerations that I know of.  I can write that up in a readable form
if you think that would help.

Tom