[cxx-abi-dev] A complexity in the mangling ABI

[Ian Lance Taylor]

"Mark Mitchell" <mark at codesourcery.com> writes:

> > This is all a long-winded way of asking why the ABI says that
> > order-insensitive vendor extended type qualifiers may not be subset
> > for purposes of substitution.  If this restriction were lifted--if
> > only the standard CV-qualified type could not be subset--then I
> > believe that it would be possible to write a correct demangler which
> > was not aware of all vendor extended type qualifiers.
> 
> The paragraph you quoted talks about "the grammar" but as with many aspects
> of the ABI specification, the wording is not ideal.  I think that paragraph
> means to be talking about the ordering requirements on something like "const
> volatile int"; the ABI specifies the order in which the "C" and "V" appear,
> and requires that vendor-extended qualifiers appear in alphabetical order.

Well, to be nit-pickingly precise, the ABI only specifies that
*order-insensitive* vendor-extended qualifiers appear in alphabetical
order, and they must appear before the standard CV-qualifiers.

This makes sense, since if the qualifier is order sensitive, then the
ABI can't really mandate the order in which it appears.  It has to
appear in the appropriate order.

> The specification doesn't actually say how to deal with mangling
> order-sensitive qualifiers.

I think you meant to say order-insensitive here.  (I know that I'm
confused about the difference.)

> If there are vendor-extended order-sensitive qualifiers, that would clearly
> need to change.

Again, I think you mean to say order-insensitive.

g++ supports one vendor-extended type qualifier, and it handles it in
an order-sensitive manner.

I realize that I got confused between order-sensitive and
order-insensitive in part of my earlier note.  I said 

``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''

but the last words should have been ``order-sensitive.''

> As for adding additional substitution candidates (like "const foo" given
> "const volatile foo", or "vendor1 foo" given "const vendor1 vendor2 foo")
> might very well increase the number of substitution candidates substantially
> without major benefit.  Once you exceed 36 substitution candidates the
> number of digits in the substitution reference increases, so that would
> increase the cost.  Furthermore, the obvious way to organize the
> substitution table in the compiler is to have a dictionary mapping types to
> substitution numbers; if "const volatile foo" resulted in adding "const foo"
> to the table you might have to create a type which would otherwise be
> unncessary.

That makes sense.  Unfortunately, following this policy with respect
to vendor extended type qualifiers makes it impossible to write a
generic demangler.

An alternative to lifting the restriction would be to extend the
restriction.  The ABI could declare that vendor extended type
qualifiers must always combine with CV-qualifiers when forming a
substitution candidate, regardless of whether the vendor extended type
qualifier is order-sensitive or order-insensitive.

Unfortunately, this would mean that the current g++ mangling of
__vector did not follow the ABI.

A slightly more complex alternative might be to say that a vendor
extended type qualifier *followed* by CV-qualifiers can not be subset.
That is, you can only substitute for the base type, or for the base
type plus the CV-qualifiers plus the vendor-extended type
qualifier(s).  I think this might work for g++ at present, because I
don't think there is a way to say ``vector of const int''--I think you
can only say ``const vector of int.''  I'm not 100% sure, though.

Ian