[155] in Pthreads mailing list archive
An idea for pthreads
daemon@ATHENA.MIT.EDU (David Wragg)
Wed Oct 25 14:42:30 1995
From: David Wragg <dpw93@ecs.soton.ac.uk>
To: pthreads@MIT.EDU
Date: Wed, 25 Oct 1995 16:31:48 +0100 (BST)
Hi,
I've been playing with you pthreads implemenation for a while now, and
I like it very much.
One thing that surprised me about it was the amount of assembly code
in each port. I'm not sure that any of the syscall assembly code is
neccesary.
First of all, to make sure I'm clear on this, here is why I think you
have the syscall code: The pthreads interface contains routines which
look like POSIX system calls. At the same time, a user level pthreads
implementation needs to call the real system calls. So the assembly
code contains C-interfaces to the system calls, much as in the
standard C library, only with different names.
My point is, why can't you simply borrow the system-call parts of the
standard C library, and change the names of the relevant symbols in
the object files.
It would go something like this:
First you grab the relevant parts of the standard C library, with a
command like:
% ld -r -o syscalls.o -u <list of system call symbols ie _write etc> /usr/lib/libc.a
This gives us syscalls.o, the C interfaces to system calls, but with
the normal names. Now we use another program to edit the symbol table
of syscalls.o to give the object file we want for pthreads:
% symtabsubst <a list of substitutions on the symbo table ie _write -> _machdep_sys_write> syscalls.o
I don't know of a UNIX command with the functionality of this
symtabsubst command, but it is a simple program. I wrote something
like this for a.out-sytle object files a year ago, which I know works
on Linux and SunOS machines.
Surely if this technique was used, together with a symtabsubst program
for common binary formats, porting pthreads would be much quicker, and
pthreads would be a fair bit smaller.
Good luck,
Dave Wragg.
