Commit Graph

10 Commits

Author SHA1 Message Date
Doug Rabson
017246d02f Add support for Thread Local Storage. 2004-08-03 08:51:00 +00:00
Alexander Kabaev
6d5d786f80 Allow threading libraries to register their own locking
implementation in case default one provided by rtld is
not suitable.

Consolidate various identical MD lock implementation into
a single file using appropriate machine/atomic.h.

Approved by:	re (scottl)
2003-05-29 22:58:26 +00:00
Thomas Moestl
a42a42e9b9 Fix the handling of high PLT entries (> 32764) on sparc64. This requires
additional arguments to reloc_jmpslot(), which is why MI code and MD code
of other platforms had to be changed.

Reviewed by:	jake
Approved by:	re
2002-11-18 22:08:50 +00:00
John Polstra
d1c02bccdc Update the asm statements to use the "+" modifier instead of
matching constraints where appropriate.  This makes the dynamic
linker buildable at -O0 again.

Thanks to Bruce Evans for identifying the cause of the build
problem.

MFC after:	1 week
2002-06-24 23:19:18 +00:00
Peter Wemm
14a55adf36 Update rtld for the "new" ia64 ABI. In the old toolchain, the
DT_INIT and DT_FINI tags pointed to fptr records.  In 2.11.2, it points
to the actuall address of the function.  On IA64 you cannot just take
an address of a function, store it in a function pointer variable and
call it.. the function pointers point to a fptr data block that has the
target gp and address in it.  This is absolutely necessary for using
the in-tree binutils toolchain, but (unfortunately) will not work with
old shared libraries.  Save your old ld-elf.so.1 if you want to use
old ones still.  Do not mix-and-match.

This is a no-op change for i386 and alpha.

Reviewed by:	dfr
2001-10-29 10:10:10 +00:00
Doug Rabson
b5393d9f78 Add ia64 support. Various adjustments were made to existing targets to
cope with a few interface changes required by the ia64. In particular,
function pointers on ia64 need special treatment in rtld.
2001-10-15 18:48:42 +00:00
John Polstra
630df077ab Solve the dynamic linker's problems with multithreaded programs once
and for all (I hope).  Packages such as wine, JDK, and linuxthreads
should no longer have any problems with re-entering the dynamic
linker.

This commit replaces the locking used in the dynamic linker with a
new spinlock-based reader/writer lock implementation.  Brian
Fundakowski Feldman <green> argued for this from the very beginning,
but it took me a long time to come around to his point of view.
Spinlocks are the only kinds of locks that work with all thread
packages.  But on uniprocessor systems they can be inefficient,
because while a contender for the lock is spinning the holder of the
lock cannot make any progress toward releasing it.  To alleviate
this disadvantage I have borrowed a trick from Sleepycat's Berkeley
DB implementation.  When spinning for a lock, the requester does a
nanosleep() call for 1 usec. each time around the loop.  This will
generally yield the CPU to other threads, allowing the lock holder
to finish its business and release the lock.  I chose 1 usec. as the
minimum sleep which would with reasonable certainty not be rounded
down to 0.

The formerly machine-independent file "lockdflt.c" has been moved
into the architecture-specific subdirectories by repository copy.
It now contains the machine-dependent spinlocking code.  For the
spinlocks I used the very nifty "simple, non-scalable reader-preference
lock" which I found at

  <http://www.cs.rochester.edu/u/scott/synchronization/pseudocode/rw.html>

on all CPUs except the 80386 (the specific CPU model, not the
architecture).  The 80386 CPU doesn't support the necessary "cmpxchg"
instruction, so on that CPU a simple exclusive test-and-set lock
is used instead.  80386 CPUs are detected at initialization time by
trying to execute "cmpxchg" and catching the resulting SIGILL
signal.

To reduce contention for the locks, I have revamped a couple of
key data structures, permitting all common operations to be done
under non-exclusive (reader) locking.  The only operations that
require exclusive locking now are the rare intrusive operations
such as dlopen() and dlclose().

The dllockinit() interface is now deprecated.  It still exists,
but only as a do-nothing stub.  I plan to remove it as soon as is
reasonably possible.  (From the very beginning it was clearly
labeled as experimental and subject to change.)  As far as I know,
only the linuxthreads port uses dllockinit().  This interface turned
out to have several problems.  As one example, when the dynamic
linker called a client-supplied locking function, that function
sometimes needed lazy binding, causing re-entry into the dynamic
linker and a big looping mess.  And in any case, it turned out to be
too burdensome to require threads packages to register themselves
with the dynamic linker.
2000-07-08 04:10:38 +00:00
Peter Wemm
7f3dea244c $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00
John Polstra
962fdc466a Fix a serious performance bug for large programs on the Alpha,
discovered by Hidetoshi Shimokawa.  Large programs need multiple
GOTs.  The lazy binding stub in the PLT can be reached from any of
these GOTs, but the dynamic linker only has enough information to
fix up the first GOT entry.  Thus calls through the other GOTs went
through the time-consuming lazy binding process on every call.

This fix rewrites the PLT entries themselves to bypass the lazy
binding.

Tested by Hidetoshi Shimokawa and Steve Price.

Reviewed by:	Doug Rabson <dfr@freebsd.org>
1999-06-25 02:53:59 +00:00
John Polstra
d5b537d01a Eliminate all machine-dependent code from the main source body and
the Makefile, and move it down into the architecture-specific
subdirectories.

Eliminate an asm() statement for the i386.

Make the dynamic linker work if it is built as an executable instead
of as a shared library.  See i386/Makefile.inc to find out how to
do it.  Note, this change is not enabled and it might never be
enabled.  But it might be useful in the future.  Building the
dynamic linker as an executable should make it start up faster,
because it won't have any relocations.  But in practice I suspect
the difference is negligible.
1999-04-09 00:28:43 +00:00