On 25/03/2014 5:16 pm, Joel Sherrill wrote:
On 3/24/2014 11:29 PM, Chris Johns wrote:
On 25/03/2014 4:41 am, Joel Sherrill wrote:
On 3/24/2014 12:36 PM, Sebastian Huber wrote:
On 03/24/2014 06:14 PM, Joel Sherrill wrote:
Hi
My most recently built toolset seems to be using pthreads instead
of the RTEMS thread code. Any ideas?
Its due to this patch:
http://git.rtems.org/rtems-tools/tree/tools/4.11/gcc/gcc-rtems-thread-model-posix-1.diff
We should really avoid using the POSIX GCC thread model. Its too
dangerous due to the silent errors.
Yes this is true but it did not fail in the way the RTEMS wrapper did
with SMP. I felt it was the lesser of 2 bad situations.
I also suspect the issue with gcc and the POSIX thread support is still
open and will need to be addressed. As far as I understand the mingw64
tools uses POSIX rather than the win32 thread model with an add on
pthread library.
We need to propose a target specific macro to gcc to do something based on
the status code. Something like a G++ run-time specific assert that the
target
can tailor. We really want to know about failures, I am not so sure that
other
targets do.
It will be hard for a user to debug random C++ run-time failures from
resource
allocation problems.
The libstdc++ code should handle this. I have raised a bug on the
locale's use of pthread_once. I wonder if something changed in the
pthread_once spec and the code was not updated because links such as
this exist ...
http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_once.html
.. yet ..
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_once.html
indicates an error code.
This raises an interesting question. Is the support in libstd++ written
around POSIX and not the wrapper API in gcc ? This issue kind of
supports it and that concerns me with our own thread model. It also
raises the testing profile we need to use for the wrapper.
FWIW having run into this problem porting things, there is a debug
printk at the
bottom of _Objects_Allocate() to report just this situation. Any
allocation of anything
with an ID fails at this single point. It is a handy debug thing but
there may be a way
to generalize this.
I think libstd and gcc need to handle this.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
