Re: [avr-gcc-list] RFC: new AVR devices in binutils

[Marek Michalkiewicz]

> I don't know if we should keep the avr85xx etc. emulations. If I understand it

That's for backwards compatibility, so that gcc and binutils don't have
to be upgraded at the same time - old gcc will work with new binutils.

> The only problem will be the Makefiles, that use ld directly. I think it is 
> not

These are broken, assembler and linker should always be called via avr-gcc
with the correct options.  Options can still be passed (-Wa,... or -Wl,...)
as needed, default crt*.o can be disabled with avr-gcc -nostartfiles etc.

> con/destructor problem. Maybe we can add the needed things to the linker
> scripts, if you implement the new emulations in binutils.

Yes, though it's a separate problem and I want to send only small patches
to Denis (I don't have CVS write access to binutils, only to GCC).  I like
the idea of .install0 ... .install4 sections as in the m68hc11 port, as
that would make it much easier to insert your own special initialization
code into gcrt1.S without recompiling that file, and without any code size
overhead when no such features are needed.  Unfortunately, the constructors
are in reverse order (please correct me if I am wrong, I'm no C++ wizard),
as otherwise they could be done by inserting simple function calls into
a special section...

Does anyone need destructors, called when main() returns or _exit is
called?  That could be done, by moving stack init to crt*.o and calling
main() as a normal function.  Destructors at least are in the right
order for simple calls in a section (again, correct me if I am wrong).

Marek
avr-gcc-list at http://avr1.org