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

[Peter Popov]

>> 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? And how to check the  
implementation on that architecture, given the source of gcc and glibc?  
IBM have modified glibc and gcc. Fortunately, I was able to locate the  
diff patches so it might be simple.


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

Peter