cdtest failure

[Joel Sherrill]

>
> 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.
>
> -- dc

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