avr-gcc-list
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]