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>
::= <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).
For example,
_ZZL2_4funcvE8variable_0
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 <[EMAIL PROTECTED]>
