From: "Vadim Lebedev" <vlebedev@aplio.fr>
To: "Gcc@Gcc.Gnu.Org" <gcc@gcc.gnu.org>
Subject: code generation for arm targets
Date: Wed, 22 Mar 2000 07:49:00 -0000 [thread overview]
Message-ID: <NDBBLAPGILEHFGLKGKCOKEPLCGAA.vlebedev@aplio.fr> (raw)
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
next reply other threads:[~2000-03-22 7:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-22 7:49 Vadim Lebedev [this message]
2000-03-22 10:11 ` Richard Earnshaw
2000-03-22 10:11 Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NDBBLAPGILEHFGLKGKCOKEPLCGAA.vlebedev@aplio.fr \
--to=vlebedev@aplio.fr \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).