[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] RFC: new AVR devices in binutils
From: |
reinhard . jessich |
Subject: |
Re: [avr-gcc-list] RFC: new AVR devices in binutils |
Date: |
Mon, 21 Jan 2002 21:31:16 +0100 |
On Mon, 21 Jan 2002, Marek Michalkiewicz wrote:
> > 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.
I understand, you are right it is needed.
>
> > 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.
Agreed.
>
> > 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
Yes, it is a separate problem.
> 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),
Yes, but this is the task of the function, which walks through the list of
constructors. The list is generated by the linker (see
binutils/ld/scripttempl/elfm68hc12.sc). It looks a little bit complicated, but
if someone is familar with this?
> as otherwise they could be done by inserting simple function calls into
> a special section...
No, the list is generated by the linker (see above). It generates the
__CTOR_LIST__ and __DTOR_LIST__.
> 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).
The list of destructors is generated by the linker (see above).
The hc11 port is a good pattern for this. They use also sections for
termianting (.fini0-4).
This approach could be used to insert some special code for simulation.
I have seen that they use the symbol _stack, which is generated by the linker.
Maybe we can use something similar to solve the problem with the stack size, if
we have only the 5 emulations.
Reinhard
--
Ing. Reinhard Jessich mailto: address@hidden
A-1190 Vienna, Goergengasse 2/2/1 phone: +43/1/3692600
http://members.telering.at/jessich mobile: +43/664/1735439
avr-gcc-list at http://avr1.org