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

[Marek Michalkiewicz]

On Fri, Mar 07, 2003 at 06:32:03PM +0100, Harald Kipp wrote:
> You compiler/libc guys broke it so often, that I became used
> to it and would otherwise miss something. :-)

Sorry for the inconvenience, but we really want to make things
better, it's just that sometimes the good ideas come too late...
I was hoping that the GCC 3.2 -> 3.3 incompatible changes would
be the last big ones.  On the other hand, I was hoping for the
same before GCC 3.0, too ;-)

> IMHO, code space is typically no problem, but every
> wasted data byte is unacceptable when programming for
> small devices. I'd vote for keeping main non-return.

On the other hand, if you know for sure that main() never returns
(usual in small applications), you can still use these two bytes
(addressed by absolute pointer) if you are really desperate ;-)

Old versions of GCC could sometimes put constants in the data
section, then load them with "lds".  This has been eliminated.

The special handling of main() also affects avr-gdb, where this
prologue scanning stuff is already very complicated (to put it
mildly - I'm not sure if it still works in all cases...).

So, making main() a normal function may be an inconvenience on
small devices (2313, 2323, 2343, tiny26), but should hopefully
make things more maintainable in the long run, and good for
mega8 and larger devices.  It's a compromise...

> I can't see any incompatibility here. I don't care, if the linker
> fetches .init2 from gcrt1.S or any library. Should I?

It's just that avr-gcc and avr-libc will have to be upgraded at
the same time, again.  One nice thing about this change would be
that you can easily provide your own code to replace the library
code, because libgcc.a is linked last.

The same has already happened with the loops to copy initialized
data and clear BSS (originally in gcrt1.S, now in libgcc.S).

BTW, since C++ constructors are called from .init6, the RTOS
initialization probably should be a bit earlier (like .init5).

Marek