c++ std::thread

[Jeff Webb]

I am trying to use the C++11 std::thread class under RTEMS, but I am having trouble.  Although my desired target is a Zynq ARM-based system, I have switched over to using the SPARC simulator SIS BSP, as suggested here:

   https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start

By doing this, I hope to accelerate the debugging process and to enable others to easily reproduce my results.  If this is not the preferred platform for this task, please let me know.

It looks like other users have tried to get std::thread to work, but I have not seen any reports of success.  Here are some of the mailing lists posts I have found regarding C++11 threads:

   [1] https://lists.rtems.org/pipermail/users/2015-July/029304.html
   [2] https://lists.rtems.org/pipermail/devel/2014-December/009519.html
   [3] https://lists.rtems.org/pipermail/devel/2015-October/012680.html

 From what I have read, it sounds like this feature is of interest to others, and should be close to working.  My hope is to find a solution that will enable this feature to work right "out of the box" in the future.  I am willing to do whatever leg work I can to grind this thing out, but it looks like I will need some assistance from some folks with more expertise.

I started this process a couple of months ago using the Zynq-based ZedBoard, and had some success:

   [4] https://lists.rtems.org/pipermail/users/2015-September/029473.html

Although I was finally able to compile and run a std::thread application for the Zynq target, the join() call failed to work properly.  I was unable to create a joinable thread, no matter what I tried.  I began to suspect that something was wrong under the hood, so I switched over to the SPARC simulator SIS BSP, but I was unable to get the code to run on that platform.  Now, I am taking a step back and trying to get that to work.

I am still using the code I checked out at the end of September, so please let me know if there have been changes since then that I need to incorporate.  My first build attempt resulted in the "'thread' is not a member of 'std'" message as reported in [1].  After this, I added the "enable-threads=posix" option, switched to a git checkout of newlib, and modified pthread.h to include "sched.h", as I reported here:

   [5] https://lists.rtems.org/pipermail/users/2015-September/029480.html

After this, I still got the exception:

  terminate called after throwing an instance of 'std::system_error'
    what():  Enable multithreading to use std::thread: Not owner

In my previous attempt, I hacked __gthread_active_p() in libgcc/gthr-posix.h to always return 1 to get past this error.  For this attempt, I looked into the code a little further and got past this error by referencing pthread_cancel in my code.  Unfortunately, things still do not quite work.  I get this result:

$ sparc-rtems4.11-gdb  o-debug/posix_cxx.exe
(gdb) tar sim
Connected to the simulator.
(gdb) load
(gdb) t
No thread selected
(gdb) r
Starting program: /home/sw/rtems/jeff_examples/posix_cxx/o-debug/posix_cxx.exe
Unexpected trap ( 2) at address 0x00000000
illegal instruction
[Inferior 1 (process 42000) exited normally]
(gdb) quit

Using gdb, I was able to track the problem down to:

rtems-git/c/src/../../cpukit/score/src/threadglobalconstruction.c

void *_Thread_Global_construction( void )
{
  20267dc:       9d e3 bf 98     save  %sp, -104, %sp
   /*
    *  _init could be a weak symbol and we SHOULD test it but it isn't
    *  in any configuration I know of and it generates a warning on every
    *  RTEMS target configuration.  --joel (12 May 2007)
    */
   INIT_NAME();
  20267e0:       40 00 65 e2     call  203ff68 <_init>
  20267e4:       01 00 00 00     nop
#endif

I get the illegal instruction trap when gdb tries to step into INIT_NAME

This is the objdump of _init:

0203ff68 <_init>:
  203ff68:       9d e3 bf a0     save  %sp, -96, %sp
  203ff6c:       7f ff 04 ce     call  20012a4 <frame_dummy>

Can anyone point me where to go next, or let me know what other information I can supply to help debug this problem.

Thanks in advance for any help,

-Jeff Webb