kpriv/freebsd-ports
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update to the most recent release of LinuxThreads, glibc-linuxthreads-2.1.2,

Browse source 
which is rather tightly coupled with GNU libc, unlike the older version
of this port.

LinuxThreads has added many features since it was integrated with GNU libc,
which means that a number of interfaces that were borrowed from libc_r are
no longer needed.

This updated port required a lot of reworking of the port, so there are
likely to be new bugs.
This commit is contained in:
Jason Evans 1999-12-24 01:12:08 +00:00
parent 91df3d960a
commit 4ebeef489c
Notes: svn2git 2021-03-31 03:12:20 +00:00 
svn path=/head/; revision=23948
8 changed files with 1393 additions and 1191 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
devel/linuxthreads/distinfo
View file

@ -1 +1 @@
MD5 (linuxthreads.tar.gz) = 78d552da5758630b998142309810eb87
MD5 (glibc-linuxthreads-2.1.2.tar.gz) = 970fde93031f342358ad16d3d6ab46fe

182
devel/linuxthreads/files/README.FreeBSD
View file

@ -8,138 +8,110 @@ be using FreeBSD 4.0-current only.
Compile your applications that use Linux Threads with the following
command line options:
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -llthread -llgcc_r
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -llthread -llgcc_r
Note that the include (-I..) directive shown here should appear before any other include
directive that would cause the compiler to find the FreeBSD file /usr/include/pthread.h.
Using the FreeBSD pthread.h instead of the linuxthreads pthread.h will result in an app
fails fails in many odd and maybe spectacular ways.
Note that the include (-I<path>) directive shown here should appear before any
other include directive that would cause the compiler to find the FreeBSD file
/usr/include/pthread.h. Using the FreeBSD pthread.h instead of the linuxthreads
pthread.h will result in an app fails fails in many odd and maybe spectacular
ways.
In order to facilitate porting applications which expect a libpthread, you can create
the following symlinks if you want:
In order to facilitate porting applications which expect a libpthread, you can
create the following symlinks if you want:
ln -s /usr/local/lib/liblthread.a /usr/lib/libpthread.a
ln -s /usr/local/lib/liblthread_p.a /usr/lib/libpthread_p.a
ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so.0
ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so
/sbin/ldconfig -m /usr/lib
ln -s /usr/local/lib/liblthread.a /usr/lib/libpthread.a
ln -s /usr/local/lib/liblthread_p.a /usr/lib/libpthread_p.a
ln -s /usr/local/lib/liblthread.so.2 /usr/lib/libpthread.so.2
ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so
/sbin/ldconfig -m /usr/lib
If you do this, you can instead use:
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -lpthread -llgcc_r
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -lpthread -llgcc_r
or
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -kthread -llgcc_r
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -kthread -llgcc_r
DO NOT use libc_r with Linux Threads, and do not compile/link with
the -pthread option (which pulls in libc_r). DO link with libc
(which you will get by default).
Do not use libc_r with Linux Threads, and do not compile/link with the -pthread
option (which pulls in libc_r). Rather, link with libc (which you will get by
default).
2) You should consider enabling the posix priority extensions
in your kernel. Adding the following to your kernel config
file before you execute config and before you remake the kernel
should suffice.
2) You should consider enabling the posix priority extensions in your kernel.
Adding the following to your kernel config file before you execute config and
before you re-make the kernel should suffice.
options "P1003_1B"
options "_KPOSIX_PRIORITY_SCHEDULING"
options "_KPOSIX_VERSION=199309L"
These options are not manditory.
These options are not mandatory.
3) If you plan on having lots of threads, check the sysctl value
of kern.maxproc. Each kernel thread counts against maxproc. You
can increase maxproc by changing the MAXUSERS value in your kernel
config file. maxproc is set at 20 + 16 * MAXUSERS.
3) If you plan on having lots of threads, check the sysctl value of
kern.maxproc. Each kernel thread counts against maxproc. You can increase
maxproc by changing the MAXUSERS value in your kernel config file. maxproc is
set at 20 + 16 * MAXUSERS.
4) Be aware of the following libc issues:
a) Not all libc calls are thread safe. Many are.
In particular gmtime, localtime, etc are not thread
safe. In general, where the pthreads spec calls for "_r"
functions, these are either not provided, or if provided
are not thread safe (in most cases) and the related
libc calls are not thread safe. This differs somewhat
from the FreeBSD libc_r library, where some, but not
all, of these functions are both thread safe and have
"_r" versions.
a) Not all libc calls are thread safe. In particular gmtime, localtime, etc
are not thread safe. In general, where the pthreads spec calls for "_r"
functions, these are either not provided, or if provided are not thread safe
(in most cases) and the related libc calls are not thread safe. This differs
somewhat from the FreeBSD libc_r library, where some, but not all, of these
functions are both thread safe and have "_r" versions.
b) None of the libc calls that are supposed to be
cancellation points are implemented as such. There
is a lot of work that needs to be done on libc before
cancellation points will work correctly. Therefore,
while linux threads has the cancel functions implemented,
deferred cancellation will not really do anything, since
the co-operation needed from libc is not there.
b) Not all of the libc calls that are supposed to be cancellation points are
implemented as such. There is a lot of work that needs to be done on libc
before cancellation points will work correctly. Therefore, while linux
threads has the cancel functions implemented, deferred cancellation will not
work as required by POSIX 1003.1c-1995, since the co-operation needed from
libc is not complete.
5) There is a call implemented for FreeBSD (see stack.c):
int _pthread_setstackspacing(size_t spacing, size_t guardsize)
5) Known problems and issues:
By default, Linux Threads spaces thread stacks 2MB apart, and
makes each thread stack an "autogrow" stack. If you know that
your maximum stack for any thread can be less than that, you
can decrease the spacing by calling this function. It must
be called before any other pthreads function calls, and it
will only succeed the first time its called. Note that the
pthread TLS and the guardsize will be included in the spacing.
ie. maximum stack size = spacing - TLSpagesize - guardsize.
a) It is possible that the instructions given above for including liblgcc_r
are not sufficent. liblgcc_r is a version of libgcc_r linked against this
linuxthreads package. It is intended that applications link against this,
rather than libgcc_r (which is linked against libc_r) or libgcc (which is not
thread safe).
The spacing must be a power of 2 times the pagesize (and if its
not, it will be rounded up to the next highest value that is).
The normal gcc link options cause libgcc to be included twice in the link line
(and libgcc_r twice when linking with the -pthread option). It is therefore
possible that a custom link line needs to be generated that specifically
excludes the default libgcc and which includes liblgcc_r twice. There are no
known problems resulting from the link procedure suggested above. However,
compiling/linking with the "-v" option will illustrate the issue, where lihgcc
is included twice in addition to liblgcc_r.
6) Note that this is an older version of linuxthreads. More current
versions are at http://www.kernel.org/pub/linux/libs/glibc.
b) Since some point around Auguest 30 or later, dynamically linked SMP
applications have experienced problems with the dynamic linker. Statically
linked applications appear fine.
7) Known problems and issues:
Specifically, some applications are not able to resolve dynamic links as in
this sample output:
a) It is possible that the instructions given above for including
liblgcc_r are not sufficent. liblgcc_r is a version of libgcc_r
linked against this linuxthreads package. It is intended that
applications link against this, rather than libgcc_r (which is
linked against libc_r) or libgcc (which is not thread safe).
root@chiricahua:/usr/ports/devel/linuxthreads/work/linuxthreads-0.71/Examples [119] ./ex4
Thread 400: allocated key 0
Thread 400: allocating buffer at 0x804b400
/usr/libexec/ld-elf.so.1: /usr/local/lib/liblthread.so.0: Undefined symbol "sigfillset"
The normal gcc link options cause libgcc to be included twice
in the link line (and libgcc_r twice when linking with the
-pthread option). It is therefore possible that a custom link
line needs to be generated that specifically excludes the
default libgcc and which includes liblgcc_r twice. There are
no known problems resulting from the link procedure suggested
above. However, compiling/linking with the "-v" option will
illustrate the issue, where lihgcc is included twice in
addition to liblgcc_r.
The problem does not occur on every run, but rather intermittently, and the
undefined symbol is not always "sigfillset", thought this is common.
b) Since some point around Auguest 30 or later, dynamically linked
SMP applications have experienced problems with the dynamic linker.
Statically linked applications appear fine.
It is possible that ld-elf.so needs to be made thread safe, and that the
problem is not unique to SMP but only exposed by the higher concurrency of SMP
threads. However, the problem has not been fully diagnosed.
Specifically, some applications are not able to resolve dynamic
links as in this sample output:
c) Since August 30 or maybe later, neither this version of FreeBSD
linuxthreads nor FreeBSD user threads (libc_r) have been able to pass the ACE
Reactor_Exception_Test using FreeBSD-current. See http://www.pinyon.org/ace
for information about ACE and compiling it under FreeBSD. It is possible that
PR/15228 is another illustration of the same problem. In both cases the app
aborts at line 3314 in libgcc2.c in the __sjthrow function, because there is
no exception handler registered at that point.
root@chiricahua:/usr/ports/devel/linuxthreads/work/linuxthreads-0.71/Examples [119] ./ex4
Thread 400: allocated key 0
Thread 400: allocating buffer at 0x804b400
/usr/libexec/ld-elf.so.1: /usr/local/lib/liblthread.so.0: Undefined symbol "sigfillset"
Earlier, before August 30, both this version of linuxthreads as well] as
libc_r passed all the ACE thread tests. The cutoff date for the onset of the
problem could be later than August 30.
The problem does not occur on every run, but rather intermittently,
and the undefined symbol is not always "sigfillset", thought
this is common.
It is possible that ld-elf.so needs to be made thread safe, and that
the problem is not unique to SMP but only exposed by the higher
concurrency of SMP threads. However, the problem has not been
fully diagnosed.
c) Since August 30 or maybe later, neither this version of FreeBSD
linuxthreads nor FreeBSD user threads (libc_r) have been able to
pass the ACE Reactor_Exception_Test using FreeBSD-current. See
http://www.pinyon.org/ace for information about ACE and compiling
it under FreeBSD. It is possible that PR/15228 is another illustration
of the same problem. In both cases the app aborts at line 3314 in
libgcc2.c in the __sjthrow function, because there is no exception
handler registered at that point.
Earlier, before August 30, both this version of linuxthreads as well]
as libc_r passed all the ACE thread tests. The cutoff date for the
onset of the problem could be later than August 30.
There has not been time to fully diagnose this problem. It occurs
on both SMP and UP systems.
There has not been time to fully diagnose this problem. It occurs on both SMP
and UP systems.

8
devel/linuxthreads/files/lclone.c
View file

@ -48,10 +48,10 @@ extern int __clone __P ((int (*__fn) (void *), void *__child_stack,
/* We don't have qn equivalent to CLONE_PID yet */
if (__flags & CLONE_PID)
return (EINVAL);
return (-1);
if (__child_stack == (void *)0)
return (EINVAL);
return (-1);
/* RFTHREAD probably not necessary here, but it shouldn't hurt either */
bsd_flags = RFPROC | RFTHREAD;
@ -72,11 +72,11 @@ extern int __clone __P ((int (*__fn) (void *), void *__child_stack,
* to do anything special in this case.
*/
break;
case SIGUSR1:
case SIGUSR2:
bsd_flags |= RFLINUXTHPN;
break;
default:
return (EINVAL);
return (-1);
}
if (__flags & CLONE_VM)

2339
devel/linuxthreads/files/patch-aa
View file

File diff suppressed because it is too large Load diff

20
devel/linuxthreads/files/sched.c
View file

@ -36,6 +36,7 @@
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <errno.h>
#include "pthread.h"
#include "internals.h"
@ -49,6 +50,15 @@ int _sched_get_priority_max(int policy);
int _sched_get_priority_min(int policy);
int _sched_rr_get_interval(pid_t pid, struct timespec *interval);
int __sched_setparam(pid_t pid, const struct sched_param *param);
int __sched_setscheduler(pid_t pid, int policy,
const struct sched_param *param);
int __sched_getscheduler(pid_t pid);
int __sched_get_priority_max(int policy);
int __sched_get_priority_min(int policy);
int __sched_getparam(pid_t pid, struct sched_param *param);
int __sched_rr_get_interval(pid_t pid, struct timespec *interval);
extern int _posix_priority_scheduling;
int
@ -61,16 +71,6 @@ sched_yield(void)
return(0);
}
/* Draft 4 yield */
void
pthread_yield(void)
{
if (_posix_priority_scheduling)
_sched_yield();
else
syscall(SYS_yield);
}
#ifdef HAVE_FIXED_SCHED_FUNCTIONS
int __sched_setparam(pid_t pid, const struct sched_param *param)
{

1
devel/linuxthreads/files/uthread_file.c
View file

@ -42,6 +42,7 @@
#include "pthread.h"
#include "internals.h"
#include "restart.h"
#include "libc_spinlock.h"
/*
* Weak symbols for externally visible functions in this file:

16
devel/linuxthreads/pkg-descr
View file

@ -1,9 +1,11 @@
Linux threads is an POSIX pthreads implementation using "kernel
threads". In this FreeBSD port, a kernel thread is started using
rfork (whereas in the original Linux implementation a kernel thread
is started using the Linux clone call). This implementaion provides
a so-called one-to-one mapping of threads to kernel schedulable
entities. For more information see about the original linux threads
implementation see:
LinuxThreads is an POSIX pthreads implementation using "kernel threads". In
this FreeBSD port, a kernel thread is started using rfork (whereas in the
original Linux implementation a kernel thread is started using the Linux clone
call). This implementaion provides a so-called one-to-one mapping of threads to
kernel schedulable entities. For more information see about the original
LinuxThreads implementation see:
http://pauillac.inria.fr/~xleroy/linuxthreads/
Note that LinuxThreads has been integrated with the GNU C library (glibc) since
version 2.0, so the above URL points to dated information.

16
devel/linuxthreads/pkg-plist
View file

@ -1,12 +1,22 @@
lib/liblthread.a
lib/liblthread_p.a
lib/liblthread.so
lib/liblthread.so.0
lib/liblthread.so.2
lib/liblgcc_r.a
lib/liblgcc_r_pic.a
include/pthread/linuxthreads/pthread.h
include/pthread/linuxthreads/pthread_rw.h
include/pthread/linuxthreads/pthread_stack.h
include/pthread/linuxthreads/semaphore.h
include/pthread/linuxthreads/pt-machine.h
include/pthread/linuxthreads/useldt.h
include/pthread/linuxthreads/bits/libc-lock.h
include/pthread/linuxthreads/bits/libc-tsd.h
include/pthread/linuxthreads/bits/pthreadtypes.h
include/pthread/linuxthreads/bits/stdio-lock.h
include/pthread/linuxthreads/bits/local_lim.h
include/pthread/linuxthreads/bits/posix_opt.h
include/pthread/linuxthreads/bits/sigthread.h
@exec /sbin/ldconfig -m %D/lib
@dirrm include/pthread/linuxthreads/bits
@dirrm include/pthread/linuxthreads
@dirrm include/pthread
@unexec /sbin/ldconfig -R