This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [980205]: Patch for wrong mangling (was: Re: [980129]: bug in COFF's name mangling?)
On Mon, 9 February 1998, 12:25:39, manfred@s-direktnet.de wrote:
> On Wed, 4 February 1998, 16:33:46, Manfred.Hollstein@ks.sel.alcatel.de wrote:
>
> > 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 &)
>
> This is not only a problem with COFF/sdb, but also e.g. on Solaris and SunOS:
>
> $ strings -a fcomplex.o | grep __doami
> __doami__FPt7complex1ZfRCt7complex1Zf:F(13,3)
> __doami__H1Zf_Pt7complex1ZX01RCt7complex1ZX01_Rt7complex1ZX01
>
> As you can see, the STABS entry for the particular function uses a differently
> mangled name than the symbol itself.
>
> Doing this with an fcomplex.o from egcs-1.0's libstdc++.a gives:
> __doami__H1Zf_Pt7complex1ZX01RCt7complex1ZX01_Rt7complex1ZX01:F(13,3)
> __doami__H1Zf_Pt7complex1ZX01RCt7complex1ZX01_Rt7complex1ZX01
>
> The append patch fixes it for me in both debugging worlds. But, since I'm far
> away from being a C++ frontend expert, Mark Mitchell or Jason Merrill,
> could you please check, whether the patch is ok or the bug is caused elsewhere?
> BTW, you can reproduce the problem with the attached `bug.cc'.
>
> Mon Feb 9 12:07:56 1998 Manfred Hollstein <manfred@s-direktnet.de>
>
> * decl.c (grokdeclarator): Use DECL_TEMPLATE_INSTANTIATION as well
> when deciding to override DECL_ASSEMBLER_NAME.
>
[patch deleted]
Just ran a full build (bootstrap and check) on sparc-sun-solaris2.5.1.
Numbers didn't change compared to those I reported on Friday without
my patch. Hence, I'm quite certain, the patch doesn't introduce any
new bugs ;-) but is likely to solve at least some of the debugging
problems other reported.
Manfred