This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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


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.

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.

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>

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>?

Sorry for the runaround on all this.

Ian


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