[gccsdk] GCCSDK GCC 4 status update

gccsdk at jip22.freeuk.com gccsdk at jip22.freeuk.com
Sat Jun 2 10:50:36 PDT 2007

David J. Ruck wrote:

> On 2 Jun 2007 John Tytgat <John.Tytgat at aaug.net> wrote:
>> That's true and should probably spelt out more clearly.  Technically it
>> is not impossible to do the initialisation at module init time but there
>> is an additional twist that the SCL stubs for malloc()/free() & friends
>> are using RMA space for heap management when they are executed in SVC mode
>> (like at module init time) but application space when in USR mode (like at
>> module start time).
>> So doing the initialisation at module init time and if this would involve
>> allocating heap memory, you wouldn't be able to safely continue using
>> those objects at module start time.
>> Therefore I prefered to leave the initialisation of static objects happen
>> at start of main() like it already was.
> It would be best to treat the USR start code as a separate entity from
> the SVC side of the module (init/final/service/SWI/handlers), and have
> two different initialisations to enable each part to make full use of
> C++ contructs, but obviously not share them. There needs to be a
> mechanism for the USR side to pick up any flags set by commands or
> events on the SVC side, but this would be simple flat data and not
> objects.

You would need to be very careful. In effect you are going to end up 
with two different 'identical' static objects from one definition in 
the source, depending on which part of the program you are in, except 
the linker won't know this.

For instance, there are parts of the standard library which require 
static initialisation, std::cout for one obvious one you may want to 
use within an application. However, there are parts of the standard 
library which could be useful outside application code such as the 
containers, std::string.

You might find you get problems due to the C++ run time support e.g. 
new can throw bad::alloc which could require std::string.


More information about the gcc mailing list