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

[Joel Sherrill <joel@OARcorp.com>]

As part of executing the first thread RTEMS will run the global
constructors from "_Thread_Handler".  gcc generates a special
function to call usually named something like __init.  It
runs global exceptions and does the ctors.  Getting the linker
script and bsp_specs right is necessary even when the toolset
works.

Also you have to link with "g++" not "gcc".

http://gcc.gnu.org/ml/gcc/2002-07/msg00352.html is a good
read on ELF and everything that has to be right for it to
work.

Can you run cdtest on the sparc/erc32 target?

--joel

Courtney B. Duncan wrote:
> 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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985