c++/cfront puzzler

[Daniel Jacobowitz]

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