avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Stack pointer loaded on main entry?


From: Marek Michalkiewicz
Subject: Re: [avr-libc-dev] Stack pointer loaded on main entry?
Date: Fri, 7 Mar 2003 13:44:22 +0100
User-agent: Mutt/1.4i

On Fri, Mar 07, 2003 at 12:09:08PM +0100, Harald Kipp wrote:
> The problem is, however, that the compiler generates
> 
> main:
> /* prologue: frame size=4 */
>         ldi r28,lo8(__stack - 4)
>         ldi r29,hi8(__stack - 4)
>         out __SP_H__,r29
>         out __SP_L__,r28
> /* prologue end (size=4) */
> 
> which reloads the stack pointer. Shouldn't it look like
> this?
> 
> main:
> /* prologue: frame size=4 */
>         in r28,__SP_L__
>         in r29,__SP_H__
>         sbiw r28,4
>         in __tmp_reg__,__SREG__
>         cli
>         out __SP_H__,r29
>         out __SREG__,__tmp_reg__
>         out __SP_L__,r28
> /* prologue end (size=4) */
> 
> Is there any way to avoid overriding the stack pointer?

I'd like to change this for GCC 3.4 (3.3 branch is too
close to release, and I was afraid to break Ethernut ;-) -
stack pointer is now initialized early in gcrt1.S, so
there is no need to do it again in main() prologue.

Actually, I'd like to make main() a normal function
(called by startup code just like any other C function,
and exit() called after main() returns), but this has
some disadvantages on very small devices:

 - two bytes of stack space used for main() return address
 - exit() always linked in, even if main() never returns
 - main() would need an attribute to avoid saving registers
   (like h8300 OS_Task, and IAR __C_task).

BTW, I've just noticed a bug - the __stack symbol gets
its default value from RAMEND (device-specific), which
is the end of internal SRAM.  Everything is fine if you
leave it as the default value, but if you specify some
other value with "-Wl,--defsym,__stack=0x1ff", only the
value loaded to SP in main() will be changed.  The SP
value used by gcrt1.S initialization (necessary if there
are any C++ constructors) will be unchanged, because of
an assembler bug/feature in handling weak symbols.

To fix this, the early SP initialization should probably
be moved to libgcc, and linked into the .init2 section
by referencing a global symbol (a different one for small
devices with 8-bit SP).  But that probably means some
backwards compatibility issues again :(

Marek





reply via email to

[Prev in Thread] Current Thread [Next in Thread]