CRT, Member Initialisation, static data, constant data, global objects

[Tim]

Please advise if you can.

Presumably initialisation of members in member initialisation lists is
perfomed by 'C' run-time startup. If the CRT was never started-up would
those members be garbage? Which of these fundamental language support
features could I expect to be absent (and anything else I might have
missed):

static data zeroing
global data zeroing

static data initialisation
constant data initialisation
global data initialisation
scoped satic data initialisation

static object construction
global object construction
scoped object construction

initialisation of members in member lists

new
delete
I'm having to fix an embedded PowerPC-based platform that I never worked on
and which has many thousands of lines of lamentable source; the only
function it calls from the assembly startup code is Init_CPP_Constructors
which, in-turn, calls each constructor in an array of constructors in a
'ctors' segment. I see no other CRT startup calls; in fact, I don't even
think this is CRT code; I think it's simply a hand-made 'bare-bones'
startup. If so, would I be correct in assuming that a hefty chunk of support
features will be absent? The firmware actually uses enums, not constant data
and only has a few static variables and global data. It also has one class
with members initialised in the list; the rest have members initialised in
the constructors. My assumption is that there are quite a few oppertunuties
for disaster here; would you agree?

If anyone's wondering why I don't simply have a look using a debugger...
there isn't one... nor any trace port; I't a question of downloading to
flash and using a red LED or a green LED for diagnostic 'messages'. However,
I've just got home so even that isn't an option right now. Your help will be
greatly appreciated; your sympathy more than welcome :-)

Regards
Tim

[Thomas Matthews]

Tim wrote:

Please advise if you can.

Presumably initialisation of members in member initialisation lists is
perfomed by 'C' run-time startup. If the CRT was never started-up would
those members be garbage? Depends on the hardware. Some memory initializes itself to zeros, some
to all ones. But then if the memory was used before this program was
executed, yes, there would be garbage (unknown, random values).
Which of these fundamental language support
features could I expect to be absent (and anything else I might have
missed):

static data zeroing
global data zeroing

static data initialisation
constant data initialisation
global data initialisation
scoped satic data initialisation

static object construction
global object construction
scoped object construction

initialisation of members in member lists All of the above would not happen if the C++ Run-Time Library
was not invoked (CRTL or CRT). The above takes executable code
to perform. Somehow, the variables must be initialized.

new
delete As for these, depends on the implementation.
I'm having to fix an embedded PowerPC-based platform that I never worked on
and which has many thousands of lines of lamentable source; the only
function it calls from the assembly startup code is Init_CPP_Constructors
which, in-turn, calls each constructor in an array of constructors in a
'ctors' segment. I see no other CRT startup calls; in fact, I don't even
think this is CRT code; I think it's simply a hand-made 'bare-bones'
startup. Sounds more like a hook that a compiler manuf. provides for more
flexibility. Sounds familiar, perhaps Metware High C/C++ compiler?
You may also want to post to news:comp.arch.embedded.

If so, would I be correct in assuming that a hefty chunk of support
features will be absent? Read your compiler documentation. You haven't specified which compiler
you are using.

The firmware actually uses enums, not constant data
and only has a few static variables and global data. It also has one class
with members initialised in the list; the rest have members initialised in
the constructors. My assumption is that there are quite a few oppertunuties
for disaster here; would you agree? Can't agree or disagree since you haven't posted the code.

If anyone's wondering why I don't simply have a look using a debugger...
there isn't one... nor any trace port; I't a question of downloading to
flash and using a red LED or a green LED for diagnostic 'messages'. However,
I've just got home so even that isn't an option right now. Your help will be
greatly appreciated; your sympathy more than welcome :-) If you don't have a debugger, you should have an emulator. Writing code
then "plugging it in" to see if it works is not the best or optimimum
process for developing quality code.

Search the web for:
In-Circuit Emulator (ICE)
Emulator (followed by your processor)

Regards
Tim

At my company, the hardware folk have designed a development board
that contains all of the components for the production version, but
also a JTAG port for a debugger and test-point pins. When the code
is working using this board, they place the code into a production
version. The production version has no method for debugging the
code.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Tim]

"Thomas Matthews" <Th****************************@sbcglobal.net> wrote in
message news:pi******************@newssvr31.news.prodigy.c om...

Tim wrote:

Please advise if you can.

Presumably initialisation of members in member initialisation lists is
perfomed by 'C' run-time startup. If the CRT was never started-up would
those members be garbage?

Depends on the hardware. Some memory initializes itself to zeros, some
to all ones. But then if the memory was used before this program was
executed, yes, there would be garbage (unknown, random values).

Which of these fundamental language support
features could I expect to be absent (and anything else I might have
missed):

static data zeroing
global data zeroing

static data initialisation
constant data initialisation
global data initialisation
scoped satic data initialisation

static object construction
global object construction
scoped object construction

initialisation of members in member lists

All of the above would not happen if the C++ Run-Time Library
was not invoked (CRTL or CRT). The above takes executable code
to perform. Somehow, the variables must be initialized.

new
delete

As for these, depends on the implementation.

I'm having to fix an embedded PowerPC-based platform that I never worked on and which has many thousands of lines of lamentable source; the only
function it calls from the assembly startup code is Init_CPP_Constructors which, in-turn, calls each constructor in an array of constructors in a
'ctors' segment. I see no other CRT startup calls; in fact, I don't even
think this is CRT code; I think it's simply a hand-made 'bare-bones'
startup.

Sounds more like a hook that a compiler manuf. provides for more
flexibility. Sounds familiar, perhaps Metware High C/C++ compiler?
You may also want to post to news:comp.arch.embedded.

If so, would I be correct in assuming that a hefty chunk of support
features will be absent?

Read your compiler documentation. You haven't specified which compiler
you are using.

The firmware actually uses enums, not constant data
and only has a few static variables and global data. It also has one class with members initialised in the list; the rest have members initialised in the constructors. My assumption is that there are quite a few oppertunuties for disaster here; would you agree?

Can't agree or disagree since you haven't posted the code.

If anyone's wondering why I don't simply have a look using a debugger...
there isn't one... nor any trace port; I't a question of downloading to
flash and using a red LED or a green LED for diagnostic 'messages'. However, I've just got home so even that isn't an option right now. Your help will be greatly appreciated; your sympathy more than welcome :-)

If you don't have a debugger, you should have an emulator. Writing code
then "plugging it in" to see if it works is not the best or optimimum
process for developing quality code.

Search the web for:
In-Circuit Emulator (ICE)
Emulator (followed by your processor)

Regards
Tim

At my company, the hardware folk have designed a development board
that contains all of the components for the production version, but
also a JTAG port for a debugger and test-point pins. When the code
is working using this board, they place the code into a production
version. The production version has no method for debugging the
code.

Yes, unfortunately this is not a new product and the particular flavour of
PowerPC used is discontinued and no longer supported. Thanks for your input.
Tim