This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/14235] verbose RTTI message polluting traces
- From: "tromey at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 15 Feb 2013 19:19:02 +0000
- Subject: [Bug python/14235] verbose RTTI message polluting traces
- Auto-submitted: auto-generated
- References: <bug-14235-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14235
--- Comment #8 from Tom Tromey <tromey at redhat dot com> 2013-02-15 19:19:02 UTC ---
First, I wonder whether this reproducer is actually what
is seen in LibreOffice.
Michael, can you say? The critical part of this reproducer
is that the classes are defined locally in a function.
But, based on the names in the messages in your example,
I would guess that this is not the case for you...
The local class name problem is noted in the source as bug#8570
(the source uses the pre-renumbering PR). From gnu-v3-abi.c:
/* Try to look up the class name as a type name. */
/* FIXME: chastain/2003-11-26: block=NULL is bogus. See pr gdb/1465. */
run_time_type = cp_lookup_rtti_type (class_name, NULL);
if (run_time_type == NULL)
return NULL;
And, indeed, this is bogus. In the example, a class named "DerivedClass"
is put into the symbol table in one of the blocks making up "main".
However, looking up the vtable symbol yields _ZTVZ4mainE12DerivedClass,
which demangles as "vtable for main::DerivedClass".
Aside from the long, huge project of fixing the symbol tables, one option
might be to notice this situation and enter a second, global symbol for
the type, named "main::DerivedClass".
It isn't completely clear to me that this would work.
For example, could there be 2 symbols with this name in different CUs?
One in a function and one in a namespace?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.