ARM Thumb 2: Alignment getting lost between .ll and .s

[llvmbot]

Bugzilla Link	10128
Resolution	FIXED
Resolved on	Sep 01, 2011 18:07
Version	trunk
OS	Windows NT
Attachments	llvm code you can compile to see the problem, Assembly output from the same
Reporter	LLVM Bugzilla Contributor
CC	@asl,@d0k,@efriedma-quic,@rjmccall

Extended Description

On this .ll file, the syntax I am using is:
llc -mcpu=cortex-m3 -filetype=asm Bad.ll
Alternatively -filetype=obj.

In any case, __node_3__locals is not being aligned.
When emitted as an ELF, it places at 0x1d in .bss.
It's a 4-byte value, so this causes a crash at runtime.
The .s file doesn't have any align directives that I
can see for the value, while the .ll file does. ELF
output has this same problem, so the bug must be before
it gets that far.

This does not occur if these variables are not internalized.
Only when declared static or when internalized for global
optimization does this occur. If the symbols are exported,
the problem isn't there. Perhaps it's some optimization that
only occurs when they are local?

This bug is causing me serious problems, so please take a
look at it.

[rjmccall]

Seems to be specific to the ARM ELF code. Tiny test case:

static char c = 0;
static int x = 0;

int main() {
return c + x;
}

daysthatwere:trunk clang$ clang -cc1 -triple thumb-none-eabi /tmp/red.c -S -o -
...
.type c,%object
.lcomm c,1
.type x,%object
.lcomm x,4

daysthatwere:trunk clang$ clang -cc1 -triple thumb-apple-darwin /tmp/red.c -S -o -
...
.zerofill __DATA,__bss,_c,1,0
.zerofill __DATA,__bss,_x,4,2

[efriedma-quic]

This appears to be an issue with MCStreamer::EmitLocalCommonSymbol; it only affects non-Darwin targets which set HasLCOMMDirective to true, i.e. non-Darwin ARM and PPC. A quick workaround would be to just comment out the relevant line in ARMMCAsmInfo.cpp.

Do you happen to have an non-Darwin ARM gcc handy to see what it generates for John's test case?

[llvmbot]

This appears to be an issue with MCStreamer::EmitLocalCommonSymbol; it only
affects non-Darwin targets which set HasLCOMMDirective to true, i.e. non-Darwin
ARM and PPC. A quick workaround would be to just comment out the relevant line
in ARMMCAsmInfo.cpp.

Do you happen to have an non-Darwin ARM gcc handy to see what it generates for
John's test case?

Using LPCXpresso's arm-none-eabi-gcc, syntax being:

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -S test.c

The output is the following:

.syntax unified
.cpu cortex-m3
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.thumb
.file	"test.c"
.bss

c:
.space 1
.align 2
x:
.space 4
.text
.align 2
.global main
.thumb
.thumb_func
.type main, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
push {r7}
add r7, sp, #​0
movw r3, #:lower16:c
movt r3, #:upper16:c
ldrb r3, [r3, #​0] @ zero_extendqisi2
mov r2, r3
movw r3, #:lower16:x
movt r3, #:upper16:x
ldr r3, [r3, #​0]
add r3, r2, r3
mov r0, r3
mov sp, r7
pop {r7}
bx lr
.size main, .-main
.ident "GCC: (Code Red/Red Suite/2009_01_C) 4.3.3"

[llvmbot]

Relevant to bug 9483 ?

[efriedma-quic]

Relevant to bug 9483 ?

Yes, same codepath.

[d0k]

Fixed in r138976. (I didn't test it though due to lack of arm hardware)