libiberty (was: Re: Mangle question)

[Carlo Wood <carlo at alinoe dot com>]

On Fri, Sep 01, 2000 at 05:21:53AM +0200, Hans-Peter Nilsson wrote:
> Perhaps our definitions of "current demangler" differ, or
> something.  Though if there's a similar case that still fails,
> throw it this way.

A definite problem of "GNU" is the fact that there are so
many versions of libiberty around.  I've run into this as
a problem more than once!

I've been doing my tests using cplus_demangle from the libiberty
of binutils-2.10.0.18, which is pretty recent.

Actually, it is *because* of the fact that libiberty's version
is so unlcear that I decided to write my own demangler.

The given case caught my eye because `nm' couldn't demangle it;
`nm' is linked with the libiberty that comes with binutils.
At least a surprice to me was that directly after installing
binutils-2.10.0.18 and linking with -liberty caused my program
to be linked with a "well hidden" libiberty.a that comes with gcc,
that is.. on linux. On FreeBSD I found out that this is not the
case...
	I also dislike the fact that libiberty is only installed
as static library, not compiled with -fPIC, so I can't really use
it for my own shared library (that is what I understood from H.J.,
it seems to work for me), but on FreeBSD there turns out to be a
shared library around as well, which does NOT contain `cplus_demangle'.
	Because `libtool' forces me to use -liberty when linking with
libiberty (trying libiberty.a fails with an error) on FreeBSD it
links with the shared library, without the `cplus_demangle'.  That
was another reason for to write my own.  Then on linux it grabs the
libiberty that comes with gcc without that I can change that.

Something is not right with the version management of libiberty
imho :).

--

Ok, lemme see if any symbol in my libcw project fails to demangle
(which is the source of all the torture I applied to g++ in the
past years)...

Hmm, the symbols that are in there that the demangler can't
demangle are lot of __tfP... and __tiP... variables, for example:

__tfP8sockaddr
__tfPQ25libcwt16option_event_tct1Z12burst_app_ct
..
__tiP8sockaddr
__tiPQ25libcwt16option_event_tct1Z12burst_app_ct

All of them have a 'P' after the 'tf' or 'ti'.

My demangler makes of those:

sockaddr* type_info function
libcw::option_event_tct<burst_app_ct>* type_info function
..
sockaddr* type_info node
libcw::option_event_tct<burst_app_ct>* type_info node

Everything, except one variable, works :)
That last one doesn't seem to be a problem in the demangler,
it is (output of nm:)

0805d0e4 B _27_GLOBAL_.N.__12burst_app_ct.app_instance

This is a variable that is declared as follows:

namespace {
  // reserve static space for the application object:
  SingletonInstance<burst_app_ct> app_instance __attribute__ ((unused));
}

The `SingletonInstance' is pretty complex, let me know if you
really need it.

-- 
Carlo Wood <carlo@alinoe.com>                        -=- Jesus Loves you -=-