This is the mail archive of the gdb-prs@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]

[Bug python/14235] verbose RTTI message polluting traces


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.


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