I just got this error message from the GNU assembler: Error: alignment too large: 15 assumed Which made me laugh at first. The corresponding input line was: .align 16 Apparently what's going on here is that ".align 16" is ambiguous: on some architectures it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if it were allowed. See: http://ftp.gnu.org/pub/old-gnu/Manuals/gas-2.9.1/html_node/as_68.html I'm not sure what the best way is to fix this. If LLVM wants to support other assemblers presumably an architecture-dependency is required. Edmund -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>:> I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > > .align 16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures it means ".balign 16", and on some it means ".p2align > 16", which would mean ".balign 65536" if it were allowed. See: > > http://ftp.gnu.org/pub/old-gnu/Manuals/gas-2.9.1/html_node/as_68.html > > I'm not sure what the best way is to fix this. If LLVM wants to support > other assemblers presumably an architecture-dependency is required.On what architecture did you got the error? We have AlignmentIsInBytes in MCAsmInfo for that. It is probably wrong for your architecture.> EdmundCheers, -- Rafael Ávila de Espíndola
Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote:> I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > > .align 16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures it means ".balign 16", and on some it means ".p2align > 16", which would mean ".balign 65536" if it were allowed. See: > > http://ftp.gnu.org/pub/old-gnu/Manuals/gas-2.9.1/html_node/as_68.html > > I'm not sure what the best way is to fix this. If LLVM wants to support > other assemblers presumably an architecture-dependency is required. > > Edmund > > -- > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- A non-text attachment was scrubbed... Name: deep-llvm-comm-align.diff Type: application/octet-stream Size: 4142 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100126/a354ed13/attachment.obj>
On Tue, 2010-01-26 at 02:43, Sandeep Patel wrote:> Assuming you're working with an ARM target, you may also hit a problem > with the alignment option on the .comm directive. > > Attached is a first-cut patch for this latter problem.The particular version of the GNU assembler that I'm using doesn't accept an alignment argument to .lcomm. It does accept an alignment argument to .comm, but this is a number of bytes rather than a number of address bits. http://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_7.html suggests that the third argument to .comm (and perhaps, by analogy, the third argument to .lcomm) is always a number of bytes. So COMMDirectiveAlignmentIsInBytes might not be needed. Edmund -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Mon, 2010-01-25 at 17:56, Rafael Espindola wrote:> On what architecture did you got the error? We have AlignmentIsInBytes > in MCAsmInfo for that. It is probably wrong for your architecture.Thanks. This was on ARM, and this one-line diff against r94535 made it work for me. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-patch Size: 352 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100126/a5572f97/attachment.bin>
2010/1/25 Sandeep Patel <deeppatel1987 at gmail.com>:> Assuming you're working with an ARM target, you may also hit a problem > with the alignment option on the .comm directive. > > Attached is a first-cut patch for this latter problem.I have updated your patch to reflect the recent changes. I have also updated the tests. I have checked that it produces --------------------------- .comm bar,75,128 ---------------------------- and --------------------- .align 7 foo: -------------------- and that that is what gas for ARM expects. Chris, do you think it is OK?> deepCheers, -- Rafael Ávila de Espíndola -------------- next part -------------- A non-text attachment was scrubbed... Name: comm.patch Type: text/x-diff Size: 4706 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100126/4aac86a3/attachment.patch>