| Summary: | Macro Expansion is broken | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Eric McVicker <mcvick_e> |
| Component: | gas | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bug-binutils |
| Priority: | P2 | ||
| Version: | 2.15 | ||
| Target Milestone: | --- | ||
| Host: | powerpc-apple-darwin7.6.0 | Target: | powerpc-elf32-eabi |
| Build: | Last reconfirmed: | ||
Subject: Re: New: Macro Expansion is broken Hi mcvick_e, [The sourceware bugzilla web site appears to be down at the moment, so I am emailing this directly to you as well as the mailing list]. > During a regression build suite (since migrating from 2.14), it was found that > the macro expansion within gas is not working properly. The reason being is > whitespace. I am not sure that this is strictly speaking a bug, since GAS macros are supposed to use whitespace to separate their arguments. What has happened is that in 2.15 the code has been tightened up to enforce this rule whereas in 2.14 the code was more lax. This may not help you of course. > LADDR r3, ((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096) Are you able to arrange your macros so that either the white space is eliminated or else the entire argument is enclosed within quotations ? eg: LADDR r3, "((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096)" Alternatively can you use a .set directive to cause the expression to be evaluated before it is used by the macro ? ie: .set val,((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096) LADDR r3, val Cheers Nick Subject: Re: Macro Expansion is broken I am not able to do that. The expansion is done VIA the GNU C compiler, so it adds all of the associated whitespace to the macro expansion. Unless there's a magical way that I can get the GNU compiler to not pad macro expansions with whitespace it's outside of my hands. Thanks, -Eric -----Original Message----- From: nickc at redhat dot com <sourceware-bugzilla@sources.redhat.com> Sent: Feb 7, 2005 10:26 AM To: mcvick_e@iname.com Subject: [Bug gas/669] Macro Expansion is broken ------- Additional Comments From nickc at redhat dot com 2005-02-07 17:26 ------- Subject: Re: New: Macro Expansion is broken Hi mcvick_e, [The sourceware bugzilla web site appears to be down at the moment, so I am emailing this directly to you as well as the mailing list]. > During a regression build suite (since migrating from 2.14), it was found that > the macro expansion within gas is not working properly. The reason being is > whitespace. I am not sure that this is strictly speaking a bug, since GAS macros are supposed to use whitespace to separate their arguments. What has happened is that in 2.15 the code has been tightened up to enforce this rule whereas in 2.14 the code was more lax. This may not help you of course. > LADDR r3, ((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096) Are you able to arrange your macros so that either the white space is eliminated or else the entire argument is enclosed within quotations ? eg: LADDR r3, "((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096)" Alternatively can you use a .set directive to cause the expression to be evaluated before it is used by the macro ? ie: .set val,((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096) LADDR r3, val Cheers Nick The .set notation works well enough. Just had to change massive amounts of assembly (existing code) to work within the new constraints. |
During a regression build suite (since migrating from 2.14), it was found that the macro expansion within gas is not working properly. The reason being is whitespace. We have a number of assembly source files that get pre-processed by the GCC compiler, and it substitutes some #define references into our assembly source code. The assembly is then passed through to gas, and compiled into object code. The error occurs with the following example: ------ source example ------ .macro LADDR reg,sym lis \reg,(\sym)@ha addi \reg,\reg,(\sym)@l .endm LADDR r3, ((((((0x00380000 + 4096) + 256) + 256) + 256) + 49152) + 4096) ------ end source example ------- This same exact code will assemble flawlessly under binutils 2.14