RSB and C++ Model

[Chris Johns]

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