Geoffrey Keating wrote:
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.
With my GCC hat on, I don't think this is desirable. For ELF at least,
there's nothing that prevents us using the same name for multiple local
symbols (since "ld -r" does it). For the sake of both LTO and IMA, we
should add a feature to the assembler like:
.asm_alias x = y
that says references to "x" are emitted as references to a new "y",
distinct from all other "y" references. That would obviate the need for
multiple statics with the same name, since in the case that you want to
do this (IMA) you could instead emit them using whatever name was
convenient for generating the assembly file, and then let the assembler
emit a symbol with the correct name. That would help to meet the
objective that the output from IMA and/or LTO looks like the output from
"ld -r", modulo optimization. I think it would be great if you would
help implement that, which would then make extending the C++ ABI change
unnecessary.
Now, with my C++ ABI hat on, and assuming that the idea above is
intractable, then: (a) as you note, this is out-of-scope for the C++
ABI, if we confine ourselves to pure ISO C++, but (b) if the other ABI
stakeholders don't mind, I don't see any reason not to consider
reserving a chunk of the namespace.
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).
That's true, but is there a reason not to use the discriminator
encoding? There might well be an ambiguity, but I didn't see at first
blush. If so, that would seem most natural to me.
I do think that your proposed encoding is unambiguous, though, so it
certainly seems like a reasonable choice, especially if the
discriminator approach doesn't work.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
