This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: handle <local-source-name> in demangler
- From: Ian Lance Taylor <iant at google dot com>
- To: gkeating at apple dot com (Geoffrey Keating)
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sourceware dot org, mark at codesourcery dot com
- Date: 08 Nov 2006 00:39:44 -0800
- Subject: Re: handle <local-source-name> in demangler
- References: <20061108022520.E9F7A50A4225@geoffk5.apple.com>
gkeating@apple.com (Geoffrey Keating) writes:
> Following up on
> <http://gcc.gnu.org/ml/gcc/2006-10/msg00441.html>,
> this patch implements Mark's preferred option,
>
> <unqualified-name> ::= <operator-name>
> ::= <ctor-dtor-name>
> ::= <source-name>
> ::= <local-source-name> // new
>
> <local-source-name> ::= Z <source-name> <discriminator> // new
The mangling scheme right now has the property that you can
unambiguously tell what to do as you see each character. This
proposal breaks that property. Now 'Z' can either be the start of a
<local-source-name> or a <local-name>, which makes <name> ambiguous.
So even though Mark suggested it, I don't think this is a good
encoding.
This shows up in your patch, which does things the demangler code
doesn't do anywhere else, like refer directly to di->n, and save and
restore its position. And the save and restore does not work
correctly anyhow, since it does not reset di->next_comp.
How about adding a case to local-name?
<local-name> ::= Z <(function) encoding> E <(entity) name> [<discriminator>]
::= Z <(function) encoding> E s [<discriminator>]
::= Z E <source-name> <discriminator>
This is unambiguous, as 'E' can not appear at the start of <encoding>.
It is very unlikely that we would ever want 'E' to appear at the start
of <encoding>, since it is used in a number of places to mark the end
of a list.
Ian