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