This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 05 May 2011 14:49:14 -0600
- Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
- References: <20110505162855.GA2546@adacore.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