Re: [libstdc++] Make use of runtime demangler

[Mark Mitchell <mark at codesourcery dot com>]

--On Friday, March 29, 2002 06:29:24 PM -0500 Phil Edwards <phil@jaj.com> 
wrote:

> This builds the new __cxa_demangle'r into the C++ support library.
>
> We link to cp-demangle.c and dyn-string.c, then compile them locally into
> v3. Two important notes:
>
> 1) Those two files do not build warning-free because in the v3 build,
>    -DHAVE_CONFIG_H is not passed (thus the headers for malloc and whatnot
>    are not included) because we can't give it the config.h from libiberty.
>    I played with building a symlink to libiberty's config.h but I don't
>    know the multilibs scenario well enough.  Help is requested.  For now,
>    we pass -Wno-error in the special build rules.

I believe we need to fix this, or risk problems on platforms where ints
and pointers do not have the same size.

> 2) All the code to make the demangler part of the runtime lib is guarded
>    by IN_LIBGCC2.  In v3-land, we could claim to be libgcc, but that
>    would be both (a) a confusing blatant lie, and (b) not enough, because
>    cp-demangle.c exports three functions, two of which we /must not/ allow
>    into the .o file, else they will collide with the ones in libiberty.a
>    whenever that's linked into a C++ program.
>
>    (The functions are is_gnu_v3_mangled_*, declared in demangle.h.
>    Marking them local in the symver map won't work because not all systems
>    use the symver map.)
>
>    So, we introduce a new guard macro, IN_GLIBCPP_V3, and use it alongside
>    IN_LIBGCC2.  We also use it to /not/ compile the extra two functions.

We should probably remove the IN_LIBGCC2 stuff.  In the intial version of
this stuff (this is before libsupc++, when runtime support for C++ was
in libgcc) that made sense.  Now, it doesn't.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com