ide driver code - still problems

[gregory.menke at gsfc.nasa.gov]

 > 
 > I still have problems and have no idea how to track them down.
 > Here is a more detailled descrtion (see also the 1st mail):
 > 
 > I have integrated Thomas' IDE driver and built a small C example program that works.
 > Then I want to build a small C++ example because my final system should run under C++.
 > 
 > I moved the OS initialization stuff in a seperate C file. In C++ there is nothing but Init() at the moment.
 > 
 > In the IDE init code I now have the following effects:
 > - a pointer to unsigned char which I set to zero is not known by the debugger
 > - malloc of 512 bytes seems to work. I know that because
 > I stepped in the function that gets this pointer as a parameter. The strange thing is now
 > that when i make a memory dump of the area the pointer points to, ddd shows that it is the area where doneConstructor, bdctx ... and other symbols reside.
 > 
 > On the other hand I have checked that there is enough workspace available (as described in the FAQ). So I assume no problem with stack size etc.
 > 
 > Is this really a problem of switching to C++ or only a wrong assumption?
 > How can I go on to find the problem - ideas?
 > 


Not all bsp's have fully working C++ implementations.  Problems can
range from global object constructors not being called to linkscript
issues.  We've been going thru this on the mcp750 ppc bsp- there the
linkscript is OK but there were constructor invocation problems.  Joel
is thinking of doing a little work on documenting how C++ is supposed
to be arranged.  Naturally, its done differently on different
architectures....  From past conversations with him, Joel suggested
running the cdtest.exe sample program.  If it runs, your C++ is
working, if not there is a problem somewhere.

I'd suggest falling back to a very simple C++ program that exercises
the environment (like putting printf's in the constructors of global
objects), throwing/catching exceptions, etc... to test your bsp's C++.
We got the mcp750's C++ going with little effort.  You might also
create an objdump of your executable (its part of the gcc/binutils
suite).  I find xxxx-yyy-objdump -dt <exename> into one file, then the
same but piped thru sort into another file, to be very useful.  You
might try tracking the addresses of symbols as reported by gdb against
these files and see how well things match up.

Generally, C++ support seems fairly easy to arrange; the global object
constructors at least are straightforward, though linkscripts can
cause weird problems.

>From the description of your problem, it sounds somewhat like a
linkscript issue.  On the mips & ppc (and maybe others), "small" data
items can end up in a specially configured data section that works
from an implicit base register, making references to these symbols
faster/more efficient.  This often places particular requirements on
the linkscript and runtime register environment and the dependencies
are subtle to track down.  Something like this might be going wrong
when C++ is used on your bsp.

Greg