------- Comment #2 from thor at math dot tu-berlin dot de 2006-01-16 09:29
-------
HI Andrew,
even though I'm not sure whether this is a duplicate of 11774 (I'm not
competent enough to judge that), let me explain:
i) The reason why you are able to set a breakpoint here is the consequence of
the testclass having only one single (non-trivial) constructor and no base
class. The problem becomes aparent as soon as you add a second (non-trivial)
constructor and call "the wrong one", i.e. one that gdb is not aware of. As far
as I know, g++ generates more than one subroutine per constructor (is this
correct?) and gdb does not know *where* to set the breakpoint. Unfortunately,
the program where this happens here is a bit too large, and this also seems to
some part a bug in gdb.
ii) I've worked thru the gdb code last weekend. gdb does, indeed, depend on the
mangled symbol name in the dwarf output as otherwise it seems to be unable to
locate the proper symbol. It stores the linkage name ("physname" there in
gdb-speak) in its data structure, and then later uses this name to locate the
proper code section. However, at that time, it is already too late to
distinguish between the two constructors. The gdb version I'm using is the
latest, gdb 6.4, pulled off the gdb web-page. Indeed, gdb should use the
additional attributes provided with the symbol to locate the code, though it
doesn't. I don't know about the gdb authors, but it looks hard to fix this
right now, and adding the linkage name *might* help a lot here. (At least, I
was trying to fix gdb for my in-house use then to provide a patch for gdb, but
failed due to that.)
If that helps, I'll try to construct a larger non-trivial test case for it (but
then larger really means that) the bug becomes pretty anoying for a project I'm
working on, making it impossible to set breakpoints in constructors).
So long,
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25793
