cdtest failure

[Daron Chabot]

Joel Sherrill wrote:
>>
>> rying to run cdtest.exe (rtems cvs HEAD) in qemu (0.9.1) failed with  
>> the following output:
>>
>> djc at toolbox-- 
>> <http://rtems.rtems.org/mailman/listinfo/rtems-users>> qemu 
>> -no-reboot -m 128 -boot n -tftp /opt/rtems/i386- 
>> rtems/pc386/lib/rtems-4.9/tests -bootp /cdtest.exe -serial stdio
>> 2008-04-26 11:01:41.589 i386-softmmu[6716] KO
>> rtems_gxx_mutex_init
>> fatal error, exiting
>>
>> EXECUTIVE SHUTDOWN! Any key to reboot...2008-04-26 11:01:59.995 i386- 
>> softmmu[6716] KO
>>
>>
>> Inserting some instrumentation in "libcsupport/src/gxx_wrappers.c"  
>> showed that the call to rtems_semaphore_create( ) was returning an  
>> rtems_status_code of 5==RTEMS_TOO_MANY.
>>
>> Changing CONFIGURE_MAXIMUM_SEMAPHORES from 1 to 2 in cdtest's  
>> "system.h" permits the test to run to a successful conclusion.
>>
>> Questions: "where is the other semaphore being consumed" ?? and 
>> "what  has changed to require more than a single semaphore" ??
>>   
> Breaking on rtems_semaphore_create will obviously
> answer the question but I recall that g++ added
> a second mutex in recent history.
>
> Can you double check where each create is called
> from before we add one?  Just to make sure we are
> not covering up a shortage somewhere.
>
> It may make sense to add a "C++ application" configuration
> constant similar to the "NUMBER_OF_ADA_TASKS" one.  That
> hides the ugly details of what C++ will actually use.
>
> I also distinctly recall adding a semaphore to the
> configuration in my local tree but obviously I threw
> that change away and didn't commit it. :(
>
> If you can explain this, it would really help.
> I am teaching 4 days this week and doing prep work today.

Solved: the mutex problem was of my own making :-(

I forgot that lately I have been configuring RTEMS (pc386 BSP) with 
"USE_COM1_AS_CONSOLE=1". This configuration permits capture of RTEMS 
stdout to a scrollable terminal window in Qemu (with the -serial stdio 
command-line option), but it also must trigger the inclusion of an extra 
mutex (termios?) beyond that required by c++.

Doh......

Interestingly, using "objdump -S -D cdtest.exe" reveals calls to 
"rtems_semaphore_create( )" in the following:
1) rtems_gxx_mutex_init
2) rtems_libio_init
3) rtems_termios_open

New question:
Given that rtems_gxx_mutex_init( ) consumes the sole semaphore 
configured for the Workspace, why does printf(), used for 
instrumentation in cdtest.exe, NOT require configuration for another 
semaphore (i.e 2 in total)?

If I #define RTEMS_TEST_IO_STREAM in cdtest (to drag in cin/cout/cerr 
machinery) I have to change CONFIGURE_MAXIMUM_SEMAPHORES from 2 (with 
USE_COM1_AS_CONSOLE=1) to 5:

Is that one mutex for gxx_mutex_init, one for termios, and three for 
cin/cout/cerr ??

-- dc