> >
> > Actually, this might be much easier (better?) to call constructors
> > in main's code just before first main's instruction after stack
> > initialization, but then user cannot pass parametres to main().
>
> I think in the C++ spec, the constructors are supposed to be run before
> main is run, is it a bit of a hack to put it in the prologue of main?
Basically, yes.
However, as long as main() in embedded does not accept parameters,
the hidded ctors call will not change anything.
But, if user puts his own routine in initX, he can make main accepting args.
Then this will destroy things a bit.
>
> Hmm, is there some solution to this, the AVR sets up the stack pointer
> in the .init2 section.
>
> Ok I see in the AVR port that the stack pointer gets initialized twice,
> once in init2 (in avr-libc/crt1/gcrt1.S) and once in the main prologue
> (in gcc/config/avr/avr.c avr_function_prolog).
>
So, with C++ code msp430gcc will do the same.
> I has always assumed that if you wanted to reserve ram like using the
> RESERVE_RAM, that it would be done in the linker script, its the thing
> to control where things are put into memory.
>
RESERVE_RAM(x) actually shifts initial stack value from user code, not from
linker script.
The mentioned problem can be avoided by passing '-mstack=...' or --defsym... .
> Its a bit of a hack but, maybe in the main prologue we could change to the
> .init2 section put the stack code in then change back to the .text
> section this would get the stack pointer initialized before the
> constructors are run and would allow the RESERVE_RAM to also work. Or I
how??? RESERVE_RAM(x) is an attribute and cannot not affect any library code.
> just had a thought, define a symbol here in the main prologue to be the
> start of stack then use it in .init2 section to set the stack to the
> same place. This symbol could be defined week so it could also be over
> ridden by the linker script.
>
> This would be in gcc/config/msp430/msp430.c
>
> msp430_function_prologue(file, size)
> {
> ....
> if (main_p)
> ....
> }
>
> > Actually, this might be much easier (better?) to call destructors
> > just before returning from main(). But then destructors will not
> > be called when execution aborts with abort().
>
> I like the current way, the destructors in a separate section, so they
> can be deleted with the linker when not required.
>
Obviously, if ctors/dtors are not required, gcc will not issue a relevant
code.
cheers,
~d
> Regards,
--
/********************************************************************
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314
********************************************************************/