Re: [avr-gcc-list] stack layout

[Marek Michalkiewicz]

Hello,

On Fri, Jun 24, 2005 at 09:57:15PM +0200, Joerg Wunsch wrote:

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

Good.  I didn't think it would be so simple to fix (no need to set
the value of __stack in a separate source file) - thanks.

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

Making main() a normal function would be a good idea (if the "it's OK
to clobber all registers" attribute is implemented).  I think the code
for decrementing the stack pointer is no big problem - happens only
when main() needs local variables on stack (if it doesn't, stack
pointer needs no changes at all, so in this case it is a win), and
there is only one main() in the whole application...

The stack may be used before main() if there are any C++ constructors.
This was the reason for adding the early stack initialization (with
the weak symbol bug, for which you've just found a nice elegant fix).

> 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.)

Correct me if I am wrong, but your avr-libc change shouldn't break
GCC (stable or mainline) in any way.  If main() has no local variables
on stack, the stack initialization in its prologue is simply redundant
(loads the same value that was already there), but doesn't hurt.

So, I think: go ahead and commit it to avr-libc - and making main()
a normal function can be the next step (in GCC mainline, no need to
backport that to the stable version).

Thanks,
Marek