puzzled: fork +libthr

[Daniel Eischen]

On Sun, 17 Apr 2011, Andriy Gapon wrote:

> on 17/04/2011 18:21 Daniel Eischen said the following:
>> On Sun, 17 Apr 2011, Andriy Gapon wrote:
>>
>>> on 16/04/2011 14:46 Andriy Gapon said the following:
>>>> The second puzzle is the EPERM return value itself, on stable/8.
>>>> From what I seem chromium does a bunch of forks before it gets to the place of
>>>> interest.  My debugging shows that those forks are "single-threaded" (i.e. code
>>>> in thr_fork.c is not called).  And then in a process/thread that makes that
>>>> pthread_cond_wait call I see that libthr and kernel have different opinions
>>>> about what current TID is.  Userland part uses what is actually a kernel TID of
>>>> its parent thread (the one that called fork).  And given how the work is divided
>>>> between userland and kernel in libthr, that mismatch leads to serious
>>>> consequences.
>>>>
>>>> So my question is why libthr doesn't see its actual TID.  Maybe some
>>>> initialization code is not invoked.  BTW, chromium is linked to both libc and
>>>> libthr (per ldd).  But it seems that there are no pthread calls up the fork
>>>> chain until that pthread_cond_wait call.
>>>
>>> The second problem seems to be caused by chrome binary being linked to libc and
>>> libthr in "incorrect order", libc comes before libthr in ldd output.  My
>>> debugging shows that fork is resolved from libc, not from libthr.
>>> Not sure what to blame here:
>>> - build toolchain for putting libc before libthr
>>> - rtld for not preferring libthr over libc
>>> - libc/libthr for being split into two pieces in the current way
>>
>> - The build procedure for chromium.
>>
>> libc/[libc_r, libpthread, libthr] have always behaved that
>> way since the libc/libc_r split.
>
> Well, I wouldn't blame it so expressly: -pthread is the first option on the
> linkage command line, there is -lc there also.  I would expect that that would
> do the right thing, but it doesn't.  And that's a PITA for porting.

ports have been doing the right thing for years; I think they
probably just remove the explicit -lc because -lc is implied.
I'm not saying that you couldn't change the linker to ignore
-lc, but we've gotten (so far) without it.  I recall it was
a little bit of work to get some ports to behave correctly,
but it was very managable.

But perhaps @ports has a different view of history ;-)

-- 
DE