C++ name mangling for local entities

[Mark Mitchell]

Geoffrey Keating wrote:
> For GCC, I've found it necessary to have a way to name local (that is,
> namespace-scope 'static') variables and functions which allows more
> than one such symbol to be present and have distinct mangled names.

With my GCC hat on, I don't think this is desirable.  For ELF at least, 
there's nothing that prevents us using the same name for multiple local 
symbols (since "ld -r" does it).  For the sake of both LTO and IMA, we 
should add a feature to the assembler like:

    .asm_alias x = y

that says references to "x" are emitted as references to a new "y", 
distinct from all other "y" references.  That would obviate the need for 
multiple statics with the same name, since in the case that you want to 
do this (IMA) you could instead emit them using whatever name was 
convenient for generating the assembly file, and then let the assembler 
emit a symbol with the correct name.  That would help to meet the 
objective that the output from IMA and/or LTO looks like the output from 
"ld -r", modulo optimization.  I think it would be great if you would 
help implement that, which would then make extending the C++ ABI change 
unnecessary.

Now, with my C++ ABI hat on, and assuming that the idea above is 
intractable, then: (a) as you note, this is out-of-scope for the C++ 
ABI, if we confine ourselves to pure ISO C++, but (b) if the other ABI 
stakeholders don't mind, I don't see any reason not to consider 
reserving a chunk of the namespace.

> What I currently have implemented is
> 
>     <unqualified-name> ::= <operator-name>
>                        ::= <ctor-dtor-name>
>                        ::= <source-name>
> 		       ::= <local-source-name>   // new
> 
>     <local-source-name> ::= L <number> _ <source-name>   // new
> 
> It's distinguishable from the other possibilies, because operator-name
> starts with a lowercase letter, ctor-dtor-name starts with 'C' or 'D',
> and source-name starts with a digit.  There is no semantic meaning
> attached to the number in a local-source-name, it exists only to keep
> different names distinct (so it is not like <discriminator> in a
> local-name).

That's true, but is there a reason not to use the discriminator 
encoding?  There might well be an ambiguity, but I didn't see at first 
blush.  If so, that would seem most natural to me.

I do think that your proposed encoding is unambiguous, though, so it 
certainly seems like a reasonable choice, especially if the 
discriminator approach doesn't work.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713