[fpc-devel] porting fpc to Blue Gene/P: a cthreads bug

[Jonas Maebe]

On 29 Jul 2009, at 22:28, Peter Popov wrote:

>>> I was able to trace it to the unwinding of the gcc exception  
>>> handler for the terminating thread. An obvious assertation fails  
>>> (in unwind-dw2.c), which means that some basic startup data of gcc  
>>> is either 1) messed up 2) not initialized.
>>
>> The problem is probably that FPC either does not generate DWARF CFI  
>> info for Linux/PowerPC, or that the DWARF CFI info it generates is  
>> wrong.
>
> Do you know where to look for these things?

No. The only thing I've ever done regarding DWARF CFI is disable its  
generation in FPC for Darwin because it was broken there.

>>> So, I have two related questions:
>>> 1. Is the pthread_exit(...) call essential in ThreadMain?
>>
>> No. If you don't call pthread_exit, then the function resiult of  
>> ThreadMain will be reported as the thread exit value.
>
> I was looking at the implementation in kylix where there is comment  
> that "calling pthread_exit() explicitly while the thread is still  
> running prevents the thread from becoming detached before  
> termination. The later might crash a TThread.WaitFor call in a  
> different thread. It uses pthread_join which will fail if after  
> detachment and before termination." I don't know if this is relevant  
> to nptl threads, etc. On the other hand the posix manual says  
> pthread is called implicitly after the thread function returns.

It is probably specific to the Kylix implementation (maybe they detach  
the thread later on otherwise). Simply not calling pthread_exit() does  
not automatically make a thread detached.

Note that by looking at the Kylix implementation in detail, you make  
it very hard for us to ever accept run time library patches from you  
for those part os the RTL, because you are tainting yourself this way  
(in the sense of copyright).


Jonas