Hi, This code compiles fine with gcc: void a$() {} int main() { a$(); } This generates invalid assembly code: void $() {} int main() { $(); } To gas, an initial $ is not allowed in an identifier, but to gcc, it is, so gcc can't simply copy the function name to the assembly output, unless $ also becomes an invalid identifier in C. The code can, of course, compile successfully with -fleading-underscore.
Sorry, forgot to mention, I'm using gcc 4.1.2 with binutils 2.17, and I also tried gcc 3.3.6 with binutils 2.16.1, which behaves the same for me.
> unless $ also becomes an invalid identifier in C. Well read: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Dollar-Signs.html it is can be but does not have to be. This works for me targetting spu-elf and powerpc64-linux-gnu (with -m32 and -m64) so this is a target issue. Really I think this is a bug in binutils for i386/x86_64 (I can reproduce it there).
Thanks for the link. I don't see how GAS could be fixed, though. How would the assembler tell the difference between $0 the constant and $0 the identifier?
Subject: Re: Invalid assembly code on initial dollar signs On Wed, 2 May 2007, truedfx at gentoo dot org wrote: > Thanks for the link. I don't see how GAS could be fixed, though. How would the > assembler tell the difference between $0 the constant and $0 the identifier? ELF supports arbitrary (possibly empty) sequences of non-NUL bytes as symbol names. GAS should, in principle, provide an escaping mechanism for assembly files to represent all such names. GCC should use that escaping mechanism as required. (It's arguable whether such escaping should be applied to asm names given to variables or whether it's the user's responsibility to include the escaping in the string passed to asm in that case.)
I think this is the same bug that I got : - this code compiles : #include <stdio.h> int main(int argc, char* argv[]) { int $a = 0; for($a = 0 ; $a < 10 ; $a++) printf("%d\n", $a); return 0; } - this one doesn't : #include <stdio.h> int main(int argc, char* argv[]) { static const char* $tr = "Hello World !\n"; int i=0; for(;$tr[i] != '\0' ; i++) fputc($tr[i], stdout); return 0; } Version used: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
New information on this bug: With gcc version 4.8.3-3 on Debian x86-64 targeting x86_64-linux-gnu, trying to get the assembly version of the following code with gcc -S: void $() {} void a() { $(); } I get: [...] call $ [...] With clang, I get: [...] callq ($) [...] Making the corresponding object file of this code with gcc -c - succeed with the assembly code generated by clang - fails with the assembly code generated by gcc with the following message: t.c: Assembler messages: t.c:30: Error: missing or invalid immediate expression `' Adding parentheses in the assembly code generated by gcc: call $ → call ($) make the object file generation succeed. Clang seems to add parentheses whenever the function name starts with a dollar sign ($).
That's good to know. Trying some more, clang does manage to get even weirder symbol names right, because gas does have a form of quoting already, and clang makes use of it. int x __asm__(")"); int main() { return x; } With clang, this works. ... movl ")", %eax ... .type ")",@object # @")" .comm ")",4,4 ... If it's simpler to implement, then instead of parenthesising, $ could alternatively be treated as a symbol that needs quoting, which is a more general solution that will work for any possible symbol name.
I tried call "$" instead of call ($) With gcc -S, I got : t.s: Assembler messages: t.s:30: Error: invalid character `"' before operand 1 I don't know if there is a way to use quoting (" ") instead of parenthesizing).
Oh, very sorry about that, I hadn't realised clang stopped using gas. clang uses its own assembler now, which supports quoted names this as a syntax extension. Now that there is a possible syntax already, perhaps that will be easier to bring to gas. gas does indeed seem to properly handle your suggestion of parenthesised identifiers on x86-64 already, even if they have names such as $0 (unlike clang's assembler, oddly). However, I do worry that this may be too brittle, because of other systems (even using gas) where $ is used more extensively in standard syntax, such as register names, where parentheses cannot be used to force interpretation as a symbol name because register names may also be parenthesised.
So, a long term solution would be to allow quoted function names with the call instruction in gas?
Confirmed.
*** Bug 52554 has been marked as a duplicate of this bug. ***
*** Bug 46163 has been marked as a duplicate of this bug. ***
*** Bug 45591 has been marked as a duplicate of this bug. ***
Dup of bug 91298 . *** This bug has been marked as a duplicate of bug 91298 ***