Re: [980129]: bug in COFF's name mangling?

[Manfred dot Hollstein at ks dot sel dot alcatel dot de]

On Tue, 3 February 1998, 14:25:34, Manfred.Hollstein@ks.sel.alcatel.de wrote:

 > Hi,
 > 
 > I'm just trying to build egcs on my various systems. Solaris and SunOS
 > are  finished and work ok, but  on m88k-motorola-sysv3  (a COFF system
 > with SDB debugging info)   I'm  running into trouble   while  building
 > libstdc++, namely the bigstmp-complx stuff. I don't know, if this is a
 > common problem or something m88k specific, the build  on my other COFF
 > system (m68k-motorola-sysv) usually takes 3.5 days (and nights) and is
 > still running.
 > 
 > Initially GNU as was complaining about `C_EFCN out of scope'; this one
 > could be avoided  by using Motorola's native assembler  - but this one
 > then failed later on on some GNU as extensions used for *comio.o :-(
 > 
 > Anyway, looking at fcomplex.o on this system shows _two_ names for one
 > address:
 > 
 > $ nm --dem fcomplex.o | grep __doami
 > 00001030 T __doami(complex<float> *, complex<float> const &)
 > 00001030 T complex<float> & __doami<float>(complex<float> *, complex<float> const &)
 > 
 > while e.g. on SunOS I'll only get _one_ function name:
 > 
 > $ nm --dem fcomplex.o | grep __doami
 > 00001300 T complex<float> & __doami<float>(complex<float> *, complex<float> const &)

I now know this is caused by the following code:

varasm.c:assemble_start_function contains:

#ifdef SDB_DEBUGGING_INFO
  /* Output SDB definition of the function.  */
  if (write_symbols == SDB_DEBUG)
    sdbout_mark_begin_function ();
#endif

sdbout.c:
/* Output sdb info for the current function name.
   Called from assemble_start_function.  */

void
sdbout_mark_begin_function ()
{
  sdbout_symbol (current_function_decl, 0);
}

and sdbout_symbol then has:

    case FUNCTION_DECL:
      /* Don't mention a nested function under its parent.  */
      context = decl_function_context (decl);
      if (context == current_function_decl)
	return;
      /* Check DECL_INITIAL to distinguish declarations from definitions.
	 Don't output debug info here for declarations; they will have
	 a DECL_INITIAL value of 0.  */
      if (! DECL_INITIAL (decl))
	return;
      if (GET_CODE (DECL_RTL (decl)) != MEM
	  || GET_CODE (XEXP (DECL_RTL (decl), 0)) != SYMBOL_REF)
	return;
->    PUT_SDB_DEF (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
->    PUT_SDB_VAL (XEXP (DECL_RTL (decl), 0));
      PUT_SDB_SCL (TREE_PUBLIC (decl) ? C_EXT : C_STAT);
      break;

I guess, the two above lines should emit identical names, shouldn't they?
At least, gcc-2.8.0 and previous egcs versions did! But for e.g.

template <class _FLT> complex<_FLT>&
  __doami (complex<_FLT>* ths, const complex<_FLT>& r);

I get two different ones:

	sdef	 ___doami__FPt7complex1ZfRCt7complex1Zf
	val	 ___doami__H1Zf_Pt7complex1ZX01RCt7complex1ZX01_Rt7complex1ZX01

This means:

	IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl))
    is	__doami(complex<float> *, complex<float> const &)

while

	XEXP (DECL_RTL (decl), 0)
    is	complex<float> & __doami<float>(complex<float> *, complex<float> const &)
		
If I don't use `-g' for compilation everything is OK, but this makes debugging
C++ nearly impossible (you know why).

Robert Lipe, are you, by chance, seeing the same problems on your OpenServer
config. when using COFF?

Mark Mitchell, I know you are the one who worked very hard on the template stuff.
Could it be, that one of your latest changes broke this? I'm particularly
thinking of this change in pt.c:

	  /* Set up the context for the type_decl correctly.  Note
	     that we must clear DECL_ASSEMBLER_NAME to fool
	     build_overload_name into creating a new name.  */
	  tree type_decl = TYPE_STUB_DECL (t);

	  TYPE_CONTEXT (t) = context;
	  DECL_CONTEXT (type_decl) = context;
	  DECL_ASSEMBLER_NAME (type_decl) = DECL_NAME (type_decl);
	  DECL_ASSEMBLER_NAME (type_decl) = 
	    get_identifier (build_overload_name (t, 1, 1));

Thanks
Manfred