This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]