This is the mail archive of the
mailing list for the GCC project.
C++ name mangling for local entities
- From: gkeating at apple dot com (Geoffrey Keating)
- To: cxx-abi-dev at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Thu, 19 Oct 2006 14:55:04 -0700 (PDT)
- Subject: C++ name mangling for local entities
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.
Since the variables are 'static' there are no ABI concerns, but it
would nice to do this in a way which didn't interfere with future
versions of the name mangling standard.
What I currently have implemented is
<unqualified-name> ::= <operator-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
is the second static variable named 'variable' of a global scope
static function named 'func'.
An alternative I considered was
<local-source-name> ::= <unsigned number> <identifier> . <number>
where the unsigned number was the length of "<identifier> . <number>". This
had the advantage of being parsed by existing demanglers, but the
disadvantage that the parsing would usually produce the wrong result,
of requiring the use of the '.' character which is present nowhere
else in a C++ mangled name, and of requiring the parser to look at the
whole <identifier> before seeing the '.', so I thought that was less
good than the version I currently have implemented.
What do people think? Should the ABI document mention
<local-source-name>, or at least say that 'L' is reserved? Is there
some other character or syntax that I should use? I do see that 'v'
is available for 'vendor extended operator', but unfortunately it's
set up to be used only for an operator, not an arbitrary symbol.
- Geoffrey Keating <firstname.lastname@example.org>