On 19/10/2006, at 9:17 PM, Mark Mitchell wrote:
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 = ythat 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.
On Darwin, all the DWARF information in .o files is matched by name¹ with symbols in the executable, so this won't work. There is no DWARF information in .o files produced with 'ld -r', just an index referring to the original .o files, so it's not a problem there.
¹: That is, the name in the .o file symbol table referenced by a reloc for, say, a DW_AT_pc_begin entry is matched with a STAB in the executable. Matching does not look at the DW_AT_name in the DWARF information.
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> // newIt'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.
You mean <local-source-name> ::= Z <source-name> <discriminator>? Although I think it can't conflict with an actual <local-name>, you have to at least get to the end of <source-name> and see the '_' in the discriminator before you can be sure which one you're seeing; you could have
_ZZ4func_0v // a local-source-name _ZZ4funcvE1i // a local-name _ZZZ4func_0vE1i // a local-name containing a local-source-name _ZZN5spaceZ4func_0EvE1i // valid _ZZN5spaceZ4func_0vE1i // invalidYou can't use a local-name directly (and avoid needing local-source- name at all) because - it doesn't apply to static variables, so you'd have to invent something there anyway, and - you would be unable to mangle some symbols until you'd seen every translation unit, because a function declared 'static' in one might have the same name as a function declared 'inline' in another and they might, for example, both contain static variables of the same name; the 'inline' function must get the ABI-defined discriminator values.
Certainly <local-source-name> ::= L <source-name> <discriminator>will work and is more consistent, so consider the proposal amended to have that.
smime.p7s
Description: S/MIME cryptographic signature