This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
code generation for arm targets
- To: "Gcc at Gcc dot Gnu dot Org" <gcc at gcc dot gnu dot org>
- Subject: code generation for arm targets
- From: "Vadim Lebedev" <vlebedev at aplio dot fr>
- Date: Wed, 22 Mar 2000 16:47:22 +0100
Hi,
I see some strange things in code generation for arm-elf target:
example:
// demo2.cpp
struct toto{
int a;
char (*qwerty)(int opt);
};
struct toto test;
char test_qwerty(int opt)
#if 0
{
return (opt+0x40);
}
#else
;
#endif
void init(void){
test.qwerty = test_qwerty;
}
struct xx{
char b[528];
int x[32];
};
void doit(xx*);
int main(void)
{
char fab;
struct xx s;
s.b[0] = 1;
s.b[527] = 2;
s.x[0] = 3;
s.x[31] = 4;
doit(&s);
init();
/* la ligne qui tue */
fab=test.qwerty(10);
}
The generated code is:
1 @ Generated by gcc 2.96 20000307 (experimental) for ARM/elf
2 .file "demo2.cpp"
3 gcc2_compiled.:
4 .text
5 .align 2
6 .global init__Fv
7 .type init__Fv,function
8 init__Fv:
9 @ args = 0, pretend = 0, frame = 0
10 @ frame_needed = 0, current_function_anonymous_args = 0
11 ldr r2, .L4
12 ldr r3, .L4+4
13 str r3, [r2, #4]
14 mov pc, lr
15 .L5:
16 .align 2
17 .L4:
18 .word test
19 .word test_qwerty__Fi
20 .Lfe1:
21 .size init__Fv,.Lfe1-init__Fv
22 .align 2
23 .global main
24 .type main,function
25 main:
26 @ args = 0, pretend = 0, frame = 656
27 @ frame_needed = 0, current_function_anonymous_args = 0
28 str lr, [sp, #-4]!
29 mov r2, #2
30 mov r1, #3
31 mov ip, #4
32 mov r3, #1
33 sub sp, sp, #656
34 mov r0, sp
35 strb r3, [sp, #0]
36 strb r2, [sp, #527]
37 str r1, [sp, #528]
38 str ip, [sp, #652]
39 bl doit__FP2xx
40 bl init__Fv
41 ldr r3, .L8
42 mov r0, #10
43 mov lr, pc
44 ldr pc, [r3, #4]
45 mov r0, #0
46 add sp, sp, #656
47 ldmfd sp!, {pc}
48 .L9:
49 .align 2
50 .L8:
51 .word test
52 .Lfe2:
53 .size main,.Lfe2-main
54 .global test
55 .bss
56 .align 2
57 .type test,object
58 .size test,8
59 test:
60 .space 8
61 .ident "GCC: (GNU) 2.96 20000307 (experimental)"
Take a look at line 28.
The lr register is saved in the "unallocated" stack area. The stack pointer
is updated
to include local variables frame only at line 33.
Wouln't it be safer (with respect to interrupt and signal handling) to
update the stack
pointer immiedately upon entering the function?
Another question:
It seems that in last week snapshots exception handling is completely broken
for arm
targets... Could somebody confirm it?
Thanks
Vadim
Vadim