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

[Peter Popov]

Apparently the problem was the initialization order of libc and libgcc.  
FPC links (linux-powerpc) in the following order:

cprt0.o
crtbegin.o
crti.o
.....
crtend.o
crtn.o

This was the root of the problem with pthread_exit. Instead, the correct  
order should be (according to the output of 'gcc -###'):

cprt0.o
crti.o
crtbegin.o
.....
crtend.o
crtn.o

Has anyone encountered issues related to the order of initalization of  
libc and libgcc before? I am planning to put the correct order in the BG/P  
cross compiler, however this may be a more general issue

Peter



On Wed, 29 Jul 2009 15:27:46 -0500, Jonas Maebe  
<jonas.maebe at elis.ugent.be> wrote:

>
> 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
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel



-- 
|***********************************************|
|                                               |
|  Peter Popov,                                 |
|                                               |
|  608L Blocker Bldg.                           |
|  Institute for Scientific Computation,        |
|  Texas A&M University                         |
|  College Station, Texas 77843-3404            |
|-----------------------------------------------|
|  Phone: +1 (979) 458-4644,                    |
|  Fax: +1 (979) 845-5827                       |
|                                               |
|***********************************************|