A complexity in the mangling ABI

[Carlo Wood]

On Sun, Nov 23, 2003 at 06:40:43PM -0500, Ian Lance Taylor wrote:
> The mangling ABI says this:
> 
> ``For purposes of substitution, given a CV-qualified type, the base
>   type is substitutible, and the type with all the C, V, and r
>   qualifiers plus any vendor extended types in the same
>   order-insensitive set is substitutible; any type with a subset of
>   those qualifiers is not.  That is, given a type const volatile foo,
>   the fully qualified type or foo may be substituted, but not volatile
>   foo nor const foo.  Also, note that the grammar above is written
>   with the assumption that vendor extended type qualifiers will be in
>   the order-sensitive (not CV) set.  An appropriate grammar
>   modification would be necessitated by an order-insensitive vendor
>   extended type qualifier like const or volatile.''
> 
> What I'm thinking about here is the language about vendor extended
> type qualifiers.  This paragraph states clearly that if a type has
> more than one order-insensitive qualifier, the base type is
> substitutable, and the base type with all of the qualifiers is
> substitutable, but the base type with a subset of the qualifiers is
> not substitutable.
[...]
> I believe that all of the V3 demanglers I am aware of resolve this
> issue by assuming that all vendor extended type qualifiers are
> order-insensitive, and thus that when multiple vendor extended type
> qualifiers are present, or when a vendor extended type qualifier is
> used with one or more CV-qualifiers, the type may be subset for
> purposes of substitution.

There are two reasons for this.

Firstly, the only reason that order matters in the mangled name
is in order not to have two different symbols that essentially
are the same type.  Thus:

int const volatile

and

int volatile const

much be mangled in the same way (because they ARE the same type,
you cannot overload a function by exchanging these qualifiers).
That includes all vendor specified qualifiers.

However, after all order-insensitive qualifiers are _uniquely_
ordered for the purpose of getting only a different symbol
name when they really are different, that order doesn't matter
anymore: Why not keep them in the order that they are put in?
So, a demangle should simply demangle these symbols as-if the
order is important (this is reason 1).

It does matter for the substitutions however; and the second
reason that vendor specified symbols are handled as 100%
order sensitive (which means they are NOT combined with CV-
qualifiers to make a single substitution) is because of the
grammar definition:

<type> ::=

[...]
	<substitution>
	<CV-qualifiers> <type>
	U <source-name> <type>
[...]

The standard says "everything that can be a <substitution>
form a substitution itself".  Therefore 'U <source-name> <type>'
must be a substitution by itself, for any <type>, including
<CV-qualifiers> <type>.  And thus will
U <source-name> <CV-qualifiers> <type>
cause two substitutions.

The text that you quoted says
>   Also, note that the grammar above is written
>   with the assumption that vendor extended type qualifiers will be in
>   the order-sensitive (not CV) set.
but this grammar is not given - and thus nobody implemented it.

I agree that this is a lack in the ABI that cannot be solved
by the demangler - lets just hope that the compiler WILL add
a substitution for every order-insensitive vendor qualifier,
unlike what the ABI says - otherwise all demanglers will break.
If they do that, then there is no problem.

-- 
Carlo Wood <carlo at alinoe.com>