This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
Tom> I am not sure about this plan. I think it relies on being able to
Tom> differentiate breakpoints based on canonical linespecs, but I don't
Tom> think it is always possible to construct these.
Joel> Indeed, I think it is true that there are going to be times when no
Joel> canonical linespec is ever going to be unique enough. For instance,
Joel> the rather non-sensical case where two homonym routines are implemented
Joel> on the same line of code.
One thing I realized last night is that it is not necessary to require a
breakpoint's canonical location to be a linespec. It could be some
other data structure with a more sophisticated equality algorithm.
This idea makes it possible to support a canonical descriptor of
"function named foo with no debuginfo" without requiring some convoluted
linespec representing this.
Even with this there are going to be bad cases. E.g., the case in RH
bugzilla (I think a private bug -- sorry) concerns a program that
somehow embeds two different versions of the same library. In a case
like this, many entities have the same names, file names, and line
numbers.
Tom> I keep coming back to the "simple" approach I sketched here:
Tom> http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html
Tom> I can try to write this up into a fuller proposal if you want.
Joel> Which part of your message would be the approach that you are
Joel> referring to? There are two proposals that I can see:
Joel> - the 3rd-tier breakpoint
Joel> - one multi-location breakpoint (meaning that we break on all
Joel> matches regardless)
The latter.
Joel> The second approach is going to be really be tough to me to sell
Joel> to the Ada users. This is why I emphasized this aspect in my other
Joel> email (it was lengthy, I apologize). I have some ideas on maybe
Joel> finding a way to make it match our goals, but I'd rather make sure
Joel> I know exactly what you meant.
I will read your other note again, and Jerome's, and reply soon.
Tom