stdc++ (cout) problem with RTEMS on Sparc emulator

[Courtney B. Duncan]

At 10:39 +1000 10/22/04, Chris Johns wrote:
>Courtney B. Duncan wrote:
>>
>>The questions are:  Am I on the right track in tracking down this 
>>problem?  Does C++ cout work for anybody under RTEMS?  Isn't there 
>>a printf() based cout implementation that ought to work in this 
>>situation?
>
>I use C++, libstdc++.a, the STL on a Coldfire processor with no problems.

Thanks for your quick help.  After a couple of months I'm back to this.

>Is the correct library being linked ?

I think /usr/local/erc32/sparc-rtems/lib/libstdc++.a is the correct 
one and it is the one being linked.  All the permutations of 'revb' 
'soft' and 'v8' are also present, and I've tried them with the same 
result (doesn't work).  The emulator says that it is V7, Rev C. and 
has FPU, so I don't think I need those other versions.

>If your target (sparc) tools are being built as multilib then check 
>if the library for your specific variant is being built. If it does 
>not get built, the compiler will link the default library and not 
>warn you. This can result is strange problems due to different 
>instructions.

I have verified that use of the #include file and linking with 
-lstdc++ don't cause the problem, it is when something from the 
library is used and part of it is actually pulled in that everything 
quits.  A single line like

cout << "something";

or

vector<int> something;

will do it.  By disassembling from the start point at 0x02000000, I 
see that pulling in the library radically changes the startup code, 
causing it to jump immediately to memory without valid instructions.

>If the correct library is being linked, the other area of potential 
>trouble is the atomic lock type operations. You will find this code 
>in a file called 'atomicity.h' under the:
>
>  $prefix/lib/gcc/<target stuff>/include/c++/<target>/bits
>
>directory.

There is no 'atomicity.h' file anywhere in any of my rtems-4.6.1, 
sis-3.0.5, or erc32 directories.

All of the tools are sparc-rtems-<whatever> where whatever is gcc, 
gdb, ld, as, and so forth so this all seems to be a closed, 
self-contained system.  I wonder if libstdc++.a is just incomplete or 
unsupported?

>--
>  Chris Johns

Thanks again,

Courtney
-- 
courtney.duncan at jpl.nasa.gov
818-354-8336
M/S 301-125L

"We can lick gravity but sometimes the paperwork is overwhelming." 
Dr. Wernher von Braun, circa 1957.