handle <local-source-name> in demangler

Geoffrey Keating geoffk@apple.com
Fri Nov 10 00:24:00 GMT 2006


On 09/11/2006, at 3:59 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@apple.com> writes:
>
>> 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
>
> Hmmm.  In ordinary C++ you of course can not have two different static
> functions with the same name and signature.  I assume this is because
> of g++ -combine, in which such a case could arise.

Yes; that is, in C++ you can have two different static functions with  
the same name and signature, in different translation units, but you  
usually don't care that they will both have the same mangled name.  I  
want to put them both in the same assembly file, and the assembler  
will want them to have different mangled names.

> Now, as far as I can see, you can handle that today using the
> <local-name> syntax.  You just have to change the discriminator.  I
> can see that you want to use the discriminator for myspace::foo(),
> because that is a bit simpler.  But I don't see why you have to do it
> that way.

This would also be an ABI variation.  The ABI says exactly what value  
of the discriminator must be used for any given entity in any function.

It also doesn't solve the top-level problem of giving myspace::foo()  
different names.

> If that is unacceptable for some reason, then there is nothing wrong
> with <local-name>, but you need a way for <nested-name> to include
> something with a discriminator.  Which I now see is more or less what
> you were proposing before by adding a case to <unqualified-name>.
>
> If you can definitely get away with just changing <unqualified-name>,
> then perhaps you should go back to your original proposal using 'L'.
> Mark did say that was OK.
>   <unqualified-name> ::= <local-source-name>
>   <local-source-name> ::= L <source-name> <discriminator>

Yes...  and we are now back where I started.

OK, let's take a quick vote.  Which do you prefer, 'ZE', or 'L'?  I  
have one vote for 'L' from Ian.  Would anyone else like to vote?

> It's not immediately clear to me that you only need to change
> <unqualified-name>.  After all, you can have classes that are local to
> a file as well, so with -combine you can have duplicate X::Y::j names.
> How are you planning to handle that?  Are you sure you don't need a
> <discriminator> case for <prefix>?

I don't know what you mean by "classes that are local to a file".  If  
you have a class named 'j' in namespace X::Y in two different files,  
there is only one class and it is the same in both files.  (This is  
true even if X or Y are classes instead of name spaces.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2462 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20061110/a000d27c/attachment.p7s>


More information about the Binutils mailing list