[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
Re: [avr-libc-dev] Stack pointer loaded on main entry?,
Marek Michalkiewicz <=