Either cpp or the assembler is at fault in this problem. Using gcc on the following code causes the assembler to issue the error "too many positional arguments" # Load immediate word, has to be done with 2 instructions .macro lwi reg,val lis \reg,\val@H ori \reg,\reg,\val@L .endm #define SOME_ADDR 0x80000000 #define SOME_OFFSET 0x0068 lwi r25,(SOME_ADDR+SOME_OFFSET) Using the gcc -E option reveals: lwi 25,(0x80000000 +0x0068) Hard coding the lwi statement as follows so that cpp does not touch it fixes the problem: lwi 25,(0x80000000+0x0068) This occured with binutils 2.15 and 2.16.1
Hi Earl, I would like to blame the C pre-processor here since it is inserting the unrequested space into the output, but you could also argue that the assembler's macro code ought to understand the use of parentheses to enclose an entire expression. (Using single or double quotes does not work because this prevents the C pre-processor from performing its substitions). There is a workaround for the particular test case you supplied, by using the :vararg qualifier to the last macro argument. ie .macro lwi reg,val:vararg This should allow the macro to work. I am also attaching a patch however which improves the macro handling code so that it will accept expressions enclosed in parentheses as a single argument. Please could you try this out and let me know if it works for you. Cheers Nick
Created attachment 558 [details] Support parenthesis enclosed macro arguments
I have not heard back from Earl but I believe that the patch does the right thing, so Iam going to check it in along with this ChangeLog entry: Nick gas/ChangeLog 2005-08-08 Nick Clifton <nickc@redhat.com> PR 1070 * macro.c (getstring): Treat round parentheses in the same way as angle brackets. (get_any_string): Likewise.
The patch introduces a new failure in the i386 "32-bit SVME" tests because the round parentheses that enclose a macro's argument are being stripped.
Created attachment 586 [details] preserve round parentheses Do not strip round parentheses when parsing arguments to a macro
Second patch applied to preserve the round parentheses.
(In reply to comment #6) > Second patch applied to preserve the round parentheses. > Sorry for the delay, and sorry to report it did not fix things here. I tried patch #1 and then patch #2 (on top of #1). I got the same result. I'm fairly certain I did the rebuild correctly.
The two patches also break when using macro arguments like m (x)/(y) because parsing stops after the closing parenthesis (another needed difference in behavior from processing of angle brackets). Further, the code is still unable to deal with things like m 1+(2 + 3) Finally, even though I didn't experience problems with that, I would suspect that providing standalone (or otherwise unmatched) parentheses as macro arguments gets broken by this patch.
I doubt anyone cares enough to spend effort on fixing the issues raised in comment #8. Re comment #7, Nick's patches did fix the original testcase.