Re: handle <local-source-name> in demangler

[Geoffrey Keating <geoffk at apple dot com>]

On 08/11/2006, at 4:37 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@apple.com> writes:
>
> > > 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.
> >
> > You mean, in addition to the <local-source-name> change?
>
> No, I meant that that would be the only change.  All you need is a
> new way to mangle private names, right?  So then you would get, e.g.,
>     _ZZE3foo_3

The problem is that I need a way to allow private names to appear in a  
<nested-name>, and a <local-name> cannot appear in a <nested-name>  
according to the syntax.  I am not sure if this is intentional, since  
it's contradicted by the third example in section 5.1.6, which does  
appear to have a <local-name> inside a <nested-name>, but it's what  
the syntax says.  GCC appears to do sort of what the syntax says, and  
not what the example says.  I've sent a separate message to the cxx- 
abi-dev mailing list about that issue, and also filed GCC bug 29773.

For example, I need a way to mangle

myspace::foo()::localstruct::f(myspace::foo()::otherlocalstruct *)

where 'foo()' is a 'static' function in the namespace 'myspace', and  
there might be two of them.  It might be mangled to something like:

_ZZN7myspaceZE3foo_1EvEN11localstruct1fEPZNS_ZE3foo_1EvE16otherlocalstruct

Attachment: smime.p7s
Description: S/MIME cryptographic signature