Re: c++/cfront puzzler

[Elena Zannoni <ezannoni at redhat dot com>]

Daniel Jacobowitz writes:
 > 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.
 > 

Ok, that was my impression, that we get duplicates, so I'll zap it.

Elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer