Re: [avr-gcc-list] stack layout

[Joerg Wunsch]

address@hidden (Joerg Wunsch) wrote:

>> Shouldn't the startup code also refer to the symbol __stack?

> The code in .init2 explicitly uses __stack, but that gets already
> compiled into the object file itself, rather then deferred to the
> link stage.  That looks like a bug to me.

I think the bug is in the assembler here.  The symbol __stack is
declared as a weak symbol.  The assembler should IMHO then not use
that symbol's value even though the (default) value is already known
at assembly time, but rather defer the resolution of that symbol to
the linker.

Anyway, it seems that bug can easily be overcome.  As the assembler is
one-pass only, if it does not know the value of __stack by the time it
is used inside gcrt1.S to initialize the stack pointer, it will
automatically defer the symbol's resolution to the linker, which will
then do the right thing:

Index: crt1/gcrt1.S
===================================================================
RCS file: /home/cvs/avr-libc/avr-libc/crt1/gcrt1.S,v
retrieving revision 1.5
diff -u -u -r1.5 gcrt1.S
--- crt1/gcrt1.S        1 Nov 2004 22:23:56 -0000       1.5
+++ crt1/gcrt1.S        24 Jun 2005 19:45:04 -0000
@@ -111,7 +111,6 @@
 
 #ifndef __AVR_ASM_ONLY__
        .weak   __stack
-       .set    __stack, RAMEND
 
        /* By default, malloc() uses the current value of the stack pointer
           minus __malloc_margin as the highest available address.
@@ -174,6 +173,7 @@
        brne    .__do_copy_data_loop
 #endif /* BIG_CODE */
 
+       .set    __stack, RAMEND
 #endif /* !__AVR_ASM_ONLY__ */
 
        .section .init9,"ax",@progbits


I noticed in a simple test application, when setting __stack to 0x400,
that it now gets set to 0x400 inside .init2, yet at the beginning of
main() it gets set to 0x3fd.  This is because main() needs room for
its stack frame.  So if we omit the second initialization of the stack
pointer in main() we need to treat main() as a normal function that
sets up its stack frame as any other function does (by reading the
stack pointer, decrementing it, and writing it back).  As this will
consume more code which won't be used by 99 % of the users, I guess it
would be nice to make this a compiler option.

Opinions?  Marek, what do you think about the issue?  I could commit
the above patch to avr-libc's CVS easily, but we need someone taking
care of the compiler issue.  (I could perhaps come up with a patch for
that though.)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)