[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call main ratherthan
From: |
Anatoly Sokolov |
Subject: |
Re: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call main ratherthan jumping to it |
Date: |
Wed, 14 Feb 2007 02:23:16 +0300 |
----- Original Message -----
From: "Joerg Wunsch" <address@hidden>
> As Anatoly Sokolov wrote:
>
>> These changes should be reverted:
>>
>> - if (main_p)
>> - {
>> - fprintf (file, ("\t"
>> - AS1 (ldi,r28) ",lo8(%s - " HOST_WIDE_INT_PRINT_DEC ")" CR_TAB
>> - AS1 (ldi,r29) ",hi8(%s - " HOST_WIDE_INT_PRINT_DEC ")" CR_TAB
>> - AS2 (out,__SP_H__,r29) CR_TAB
>> - AS2 (out,__SP_L__,r28) "\n"),
>> - avr_init_stack, size, avr_init_stack, size);
>> -
>> - prologue_size += 4;
>> - }
>> - else if (minimize && (frame_pointer_needed || live_seq > 6))
>> + if (minimize && (frame_pointer_needed || live_seq > 6))
>
> That would restore the old (buggy) stack pointer initialization.
>
NO! NO! NO! Code which you see in the beginning of main() function:
ldi r28, 0x5D ; 93
ldi r29, 0x08 ; 8
out 0x3e, r29 ; 62
out 0x3d, r28 ; 61
no stack pointer initialization!!!! It is function frames initialization!!!
It is no SP = RAMEND.... It is SP = FP= (RAMEND - size);
Where 'size' is size all local (unoptimized) variables.
This code compiled for ATmega32 device.
int main()
{
int i;
}
RAMEND for ATmega32 is defined as 0x85F. And SP != 0x085F, but
SP = RAMEND - sizeof(int) = 0x085F - 2 = 0x85D!!!
But, if the frame size is null it is possible to not initialize function
frames:
- if (main_p)
+ if (main_p && size != 0)
{
fprintf (file, ("\t"
AS1 (ldi,r28) ",lo8(%s - " HOST_WIDE_INT_PRINT_DEC ")" CR_TAB
AS1 (ldi,r29) ",hi8(%s - " HOST_WIDE_INT_PRINT_DEC ")" CR_TAB
AS2 (out,__SP_H__,r29) CR_TAB
AS2 (out,__SP_L__,r28) "\n"),
avr_init_stack, size, avr_init_stack, size);
prologue_size += 4;
}
It needs to be tested, probably the fream pointer (r28:r29) is required to
the compiler.
Anatoly.
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it, (continued)
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it, Bob Paddock, 2007/02/13
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it, Alexey Boyko, 2007/02/14
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it, Marek Michalkiewicz, 2007/02/13
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it, Björn Haase, 2007/02/13
- RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it, Eric Weddington, 2007/02/13
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it, Marek Michalkiewicz, 2007/02/13
- Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main ratherthanjumping to it, David Brown, 2007/02/14
- RE: [avr-libc-dev] [bug #19050] gcrt1.S should call mainratherthanjumping to it, Eric Weddington, 2007/02/14
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/13
- [avr-libc-dev] Re: [bug #19050] gcrt1.S should call main rather than jumping to it, Joerg Wunsch, 2007/02/13
- Re: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call main ratherthan jumping to it,
Anatoly Sokolov <=
- RE: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call mainratherthan jumping to it, Eric Weddington, 2007/02/14
- Re: [avr-libc-dev] Re: [bug #19050] gcrt1.S should call mainratherthan jumping to it, Anatoly Sokolov, 2007/02/15
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/16
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/16
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/16
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/17
- [avr-libc-dev] [bug #19050] gcrt1.S should call main rather than jumping to it, Anatoly Sokolov, 2007/02/17