code generation for arm targets

code generation for arm targets

[Vadim Lebedev]

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

Re: code generation for arm targets

[Richard Earnshaw]

vlebedev@aplio.fr said:
>     28		str	lr, [sp, #-4]! 

> 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?

Take another look.  The store is a pre-decrement write -- that's what the 
'!' is for.  The instruction allocates a word of stack as it writes the 
location, so there is no problem.

R.

Re: code generation for arm targets

[Nick Clifton]

Hi Vadim,

: I see some strange things in code generation for arm-elf target:
:
:     28		str	lr, [sp, #-4]!
: 
: 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. 

No its not.

: Wouldn't it be safer (with respect to interrupt and signal handling)
: to update the stack pointer immiedately upon entering the function? 

You missed the ! at the end of the instruction.  This indicates a
pre-indexed addressing mode.  In this case the instruction will
compute:

	sp  = sp - 4
	*sp = lr

so that stack pointer is updated before (or at the same time as) the
stack slot is written to.

Cheers
	Nick