This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: c++/cfront puzzler
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 8 Jan 2003 22:54:29 -0500
- Subject: Re: c++/cfront puzzler
- References: <15900.46560.706359.558994@localhost.redhat.com>
On Wed, Jan 08, 2003 at 06:36:00PM -0500, Elena Zannoni wrote:
>
> In obsoleting the cfront stuff, I ran into this (I am tossing
> this out here, just in case, while I do some more research):
>
> dbxread.c and mdebugread.c: (ignore the printf's)
>
> /* The semantics of C++ state that "struct foo { ... }"
> also defines a typedef for "foo". Unfortuantely, cfront
> never makes the typedef when translating from C++ to C.
> We make the typedef here so that "ptype foo" works as
> expected for cfront translated code. */
> else if (psymtab_language == language_cplus)
> {
>
> // printf ("TYPEDEF FORCED\n");
> // printf ("file = %s\n", objfile->name);
> // printf ("namestring = %s\n\n", namestring);
>
> /* Also a typedef with the same name. */
> add_psymbol_to_list (namestring, p - namestring,
> VAR_NAMESPACE, LOC_TYPEDEF,
> &objfile->static_psymbols,
> nlist.n_value, 0,
> psymtab_language, objfile);
> }
>
>
> I was about to ifdef this out, when I discovered that it is actually still
> executed.
>
> It happens when there is a stab entry with a 'T' (for structure) and
> no typedef (i.e. not a 'Tt' stab) and this is in a c++ file.
Sometimes, for reasons quite convoluted, GCC decides to emit the T and
Tt separately. I checked a copy of libstdc++; every :T() stab was
followed one or two stabs later by a matching Tt. So I think removing
it wouldn't hurt GCC support.
> So, for some symbols we do this anyways. But should we?
I bet it just gives us some duplicates.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer