This is the mail archive of the gdb-patches@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: [RFC] canonical linespec and multiple breakpoints ...


Hey Tom,

thanks for the feedback.

> 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.

Indeed, I think it is true that there are going to be times when no
canonical linespec is ever going to be unique enough.  For instance,
the rather non-sensical case where two homonym routines are implemented
on the same line of code.  However:

> 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.

I think that, in a case where we have matches in code with debug
info, we shouldn't even bother looking at code without debugging
info. I think that this would be reasonable. There should be other
ways for the user to break on those instances that don't have
debug info he that's really what he meant.

> 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.

Which part of your message would be the approach that you are
referring to?  There are two proposals that I can see:
  - the 3rd-tier breakpoint
  - one multi-location breakpoint (meaning that we break on all
    matches regardless)

The second approach is going to be really be tough to me to sell
to the Ada users. This is why I emphasized this aspect in my other
email (it was lengthy, I apologize). I have some ideas on maybe
finding a way to make it match our goals, but I'd rather make sure
I know exactly what you meant.

-- 
Joel


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