This is the mail archive of the gdb@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] multiple breakpoints from FILE:LINE


>>>>> "Paul" == Paul Hilfinger <hilfingr@gnat.com> writes:

 Paul> In response to

 Paul> break FUNCTION

 Paul> in C++, GDB currently presents one with a list of choices when
 Paul> FUNCTION is overloaded.  However, this is not the only case in
 Paul> which the target of a 'break' command is ambiguous.  Consider

 Paul> break FILENAME:LINENUM

 Paul> Normally, this refers to a single location in a program, but if
 Paul> this line is in the middle of a C++ template, a multiply
 Paul> #included file, or an Ada generic definition, it may refer to
 Paul> several locations.  Currently, GDB chooses one of these
 Paul> silently.

Constructors and destructors are another example of this, which is a
known probme of long standing.

 Paul> In Ada mode, AdaCore's GNAT Pro version of GDB will also
 Paul> present a menu in response to this latter case.  In addition,
 Paul> we introduced a syntax (little used, I believe) for specifying
 Paul> a line in one specific generic instance:

 Paul> break FILENAME:FUNCTION:LINENUM

 Paul> where FUNCTION here would be fully qualified.  That is, if P1
 Paul> and P2 are two different instantiations of a generic class
 Paul> defining F, then

 Paul> break something.adb:P2.F:12

 Paul> sets a breakpoint at line 12 in P2.F.

 Paul> We would like to contribute some version of both of these to
 Paul> the public sources.  Before doing so, however, we'd like to
 Paul> solicit comments.

What you describe won't help for constructors or destructors, unless
"fully qualified" means adding some ad-hoc keyword like "[in-charge]"
(as "verbose demangling" does with constructors/destructors).  That's
actually useable, and I have done that in the past as a hacky
workaround for the constructor problem, but I'm not sure if it is the
way to go for a "clean" solution.

    paul


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