Re: Mangle question

Re: Mangle question

[Mike Stump]

> Date: Mon, 28 Aug 2000 17:12:52 +0200
> From: Carlo Wood <carlo@alinoe.com>
> To: gcc@gcc.gnu.org

> I noticed that when in a mangled name a 'T' is used with an index
> larger than 9, it is appended an underscore.  This seems to make no
> sense.  Why is this done?

Makes sense to me, but that's maybe because I'm the one that thought
it up.  :-) See, back a long time ago, there was a problem handling
more than about 9 somethings.  And the mangling format, was a single
decimal digit indicating how many of them there were.  The compiler
generated them this way and the demangler and friends ate just one
digit.  Then a customer had a testcase with 12 or so of them.  By have
it done this way, we preserve backward and forwards compatibility for
99% of the code (<10 of something), and by having _[0-9]+/[^0-9] for
the new case, we then can have any number (literally) of somethings
going forward.

If the code wasn't broken from the start and if compatibility wasn't a
concern, there'd be no need to do this.

Hope you liked the story...

Re: Mangle question

[Daniel Berlin]

> 
> Makes sense to me, but that's maybe because I'm the one that thought
> it up.  :-) See, back a long time ago, there was a problem handling
> more than about 9 somethings.  And the mangling format, was a single
> decimal digit indicating how many of them there were.  The compiler
> generated them this way and the demangler and friends ate just one
> digit.  Then a customer had a testcase with 12 or so of them.  By have
> it done this way, we preserve backward and forwards compatibility for
> 99% of the code (<10 of something), and by having _[0-9]+/[^0-9] for
> the new case, we then can have any number (literally) of somethings
> going forward.
> 

Except it's been proven it's ambiguous in the present of underscored names.

We now iterate through until the first valid "parse" of the mangled name
is found.


>
If the code wasn't broken from the start and if compatibility wasn't a
> concern, there'd be no need to do this.
> 
> Hope you liked the story...
> 

Re: Mangle question

[Mark Mitchell]

>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:

    Daniel> Except it's been proven it's ambiguous in the present of
    Daniel> underscored names.

Just so that nobody wastes *too* much time on this, please remember
that GCC 3.0 will support a new mangling scheme -- and that the old
mangling code will be removed.

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

Re: Mangle question

[Daniel Berlin]

>     Daniel> Except it's been proven it's ambiguous in the present of
>     Daniel> underscored names.
> 
> Just so that nobody wastes *too* much time on this, please remember
> that GCC 3.0 will support a new mangling scheme -- and that the old
> mangling code will be removed.

Right.
The sooner i can deprecate, and then remove the cruft needed to support
the old abi, and stop fighting issues related to badly demangled names,
the better.
However, i'm just a little bitter from having to fight bugs really caused
by not being able to demangle some names properly, and they are unfixable
because their is more than one valid demangling.
I apologize for the swipe.
Hopefully we'll never move to another mangling scheme without an official
grammar.
--Dan

Re: Mangle question

[Carlo Wood]

On Mon, Aug 28, 2000 at 04:06:06PM -0700, Mike Stump wrote:
> digit.  Then a customer had a testcase with 12 or so of them.  By have
> it done this way, we preserve backward and forwards compatibility for
> 99% of the code (<10 of something), and by having _[0-9]+/[^0-9] for
> the new case, we then can have any number (literally) of somethings
> going forward.

Thanks Mike, but in this case it isn't _[0-9]+/[^0-9], you are
using [0-9]+_[^0-9].  The underscore is on the other side of the
digits :/.  For example: "...T9c..." but "...T10_c..."
It already occured to me that perhaps the idea was to use "...T_10c..."
but that is just not the case.  Could this indeed be a "bug"?

Anyway as I said, it doesn't matter.  Especially not since we're
moving to another mangling sheme.

Regards,

... O wait.  I promised to give two bugs I found in the current
demangler.  Ok...

1) destructors are demangled as: foobar::~foobar(void)
   that should be foobar::~foobar() !

2) *every* class name (of the form <digits><class-name>) can be
   prepended by an underscore in order to seperate it from a
   previous digit in a way that is not predictable.  There can
   no special circumstances reasonably be given.  Therefore, you
   must always check for an underscore when reading <digits> and
   eat it when it is there.  This is not done by the current
   demangler, which is why it fails to demangle certain constructs.
   For example:

   __vc__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0_3RepUi

                                                                                       ^
                                                                unexpected seperator __|

   The demangler I wrote over the weekend makes of this:
   basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::operator[](unsigned int)

When I get time to move to the new abi myself, I'll have to write a
demangler for that one too -- be sure that I'll run torture tests on
the new abi too then and will come up with new bugs ;).  I suppose
nobody feels like fixing the above for the old abi.

Regards,

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

Re: Mangle question

[Hans-Peter Nilsson]

> Date: Tue, 29 Aug 2000 11:58:53 +0200
> From: Carlo Wood <carlo@alinoe.com>

> ... O wait.  I promised to give two bugs I found in the current
> demangler.  Ok...

> 
> 1) destructors are demangled as: foobar::~foobar(void)
>    that should be foobar::~foobar() !

Isn't it a style issue?  I can't say I know C++ that good, but
lots of testcases say foo::~foo(void), and cc1plus doesn't
complain with -pedantic -O2 on "class foo { public:
~foo(void);}; foo::~foo(void) {}".  If the (void) is invalid
with a destructor declaration or definition, I guess you have an
issue with a missing warning or error in g++ as well.

> 2) [...]
>    __vc__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0_3RepUi

>    basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::operator[](unsigned int)

No, the mangled and demangled now matches as above (I
tested by adding to the testsuite with --format=gnu); a
correction was committed around 2000-07-24 which seem to match
your description.  All of libstdc++ (the old one) demangled
correctly after that patch, so the itch people gave me was
scratched.

Perhaps our definitions of "current demangler" differ, or
something.  Though if there's a similar case that still fails,
throw it this way.

brgds, H-P

Re: Mangle question

[Gabriel Dos Reis]

Hans-Peter Nilsson <hp@axis.com> writes:

[...]

| ... If the (void) is invalid
| with a destructor declaration or definition, I guess you have an
| issue with a missing warning or error in g++ as well.

It is not invalid.  It is sort-of an anachronism.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

libiberty (was: Re: Mangle question)

[Carlo Wood]

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 -=-

Re: libiberty (was: Re: Mangle question)

[Hans-Peter Nilsson]

> Date: Fri, 1 Sep 2000 18:32:46 +0200
> From: Carlo Wood <carlo@alinoe.com>

> 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 don't agree about an unclear-*source*-version situation, but I
agree bugs in released versions are awkward.  There's libiberty
in binutils and libiberty in GCC.  Right now(?) they're in sync,
source-wise and we all try to keep it that way (I hope).

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

An H.J. Lu release?  The official binutils 2.10 is "old" enough
to still have the bug, recently fixed as I said.  I presume
H.J. will release a new version, picking up the latest libiberty
and cplus-dem.c.

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

Which will appear to be a solution until projects A, B and C
start maintaining separate versions, or have different release
schedules...  Then we have a problem again.

> 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...

Oh, so you link your own programs to libiberty, which changes
each time you install gcc *or* binutils.{so, a}.  Ugh.

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

Right.  Perhaps something can be done, a patch submitted...

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

I'll try and take a closer look at *this* next week.

brgds, H-P