Commit Graph

31 Commits

Author SHA1 Message Date
Marcel Moolenaar
d4337d869f Fix the load64 and store64 macros, created to handle 8-byte unaligned
loads and stores (resp.) The ldq_u and stq_u instruction mask off the
lower 3 bits of the final address before loading from or storing to
the address, so as to avoid unaligned loads and stores. They do not
themselves allow loads from or stores to unaligned addresses. Replace
the macro definitions by a packed struct dereference.

Submitted by: Richard Henderson (rth at twiddle dot net)
2005-06-02 05:34:08 +00:00
John Baldwin
2939195e46 Remove these unused files before any other archs include the same bogus
file.
2004-11-12 18:05:30 +00:00
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
Alexander Kabaev
605f36fc1e No need to zero fill memory, mmapped anonymously. Kernel will
return pre-zeroed pages itself.

Noticed by:     jake
2003-03-14 21:10:13 +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
David E. O'Brien
b2bced0aef Use the new freebsd output format from Binutils 2.13.1. 2002-10-12 02:30:53 +00:00
John Polstra
e6f0183bff Remove the nanosleep calls from the spin loops in the locking code.
They provided little benefit (if any) and they caused some problems
in OpenOffice, at least in post-KSE -current and perhaps in other
environments too.  The nanosleep calls prevented the profiling timer
from advancing during the spinloops, thereby preventing the thread
scheduler from ever pre-empting the spinning thread.  Alexander
Kabaev diagnosed this problem, Martin Blapp helped with testing,
and Matt Dillon provided some helpful suggestions.

This is a short-term fix for a larger problem.  The use of spinlocking
isn't guaranteed to work in all cases.  For example, if the spinning
thread has higher priority than all other threads, it may never be
pre-empted, and the thread holding the lock may never progress far
enough to release the lock.  On the other hand, spinlocking is the
only locking that can work with an arbitrary unknown threads package.

I have some ideas for a much better fix in the longer term.  It
would eliminate all locking inside the dynamic linker by making it
safe for symbol lookups and lazy binding to proceed in parallel
with a call to dlopen or dlclose.  This means that the only mutual
exclusion needed would be to prevent multiple simultaneous calls
to dlopen and/or dlclose.  That mutual exclusion could be put into
the native pthreads library.  Applications using foreign threads
packages would have to make their own arrangements to ensure that
they did not have multiple threads in dlopen and/or dlclose -- a
reasonable requirement in my opinion.

MFC after:	3 days
2002-07-06 20:25:56 +00:00
Matthew Dillon
eebf98659e This is the same alloca() fix as was committed for i386. David O'Brien
tested the patch on -stable.

Reviewed by:	obrien
Approved by:	jdp
MFC after:	3 days
2002-06-18 05:42:33 +00:00
Peter Wemm
939bc65715 ld-elf.so.1 assumed a few too many things about the ordering of sections
produced by ld(8) (ie: that _DYNAMIC immediately follows the _GOT).
The new binutils import changed that, and the intial GOT relocation
broke.  Use a custom linker script to provide a real end-of-GOT symbol.

Update ld.so to deal with the new (faster) PLT format that gcc-3.1 and
binutils can produce.

This is probably incomplete, but appears to be working again.

Obtained from:  NetBSD
(And a fix to a silly mistake that I made by:  gallatin)
2002-02-18 02:24:10 +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
Doug Rabson
97571220e2 The support for accelerating find_symdef() with a cache was broken. This
fixes the problem and improves startup times for large applications such
as KDE2 considerably.

Reviewed by:	jdp
MFC after:	1 week
2001-10-10 07:15:01 +00:00
John Polstra
c15e7faad5 Performance improvements for the ELF dynamic linker. These
particularly help programs which load many shared libraries with
a lot of relocations.  Large C++ programs such as are found in KDE
are a prime example.

While relocating a shared object, maintain a vector of symbols
which have already been looked up, directly indexed by symbol
number.  Typically, symbols which are referenced by a relocation
entry are referenced by many of them.  This is the same optimization
I made to the a.out dynamic linker in 1995 (rtld.c revision 1.30).

Also, compare the first character of a sought-after symbol with its
symbol table entry before calling strcmp().

On a PII/400 these changes reduce the start-up time of a typical
KDE program from 833 msec (elapsed) to 370 msec.

MFC after:	5 days
2001-05-05 23:21:05 +00:00
John Polstra
cf98e66403 Fix a bug which could cause programs with user threads packages to
lock against themselves, causing infinite spinning.  Brian Feldman
found this problem when testing with Mozilla and supplied the fix,
which I have revised slightly.

Here is the failure scenario.  A thread calls dlopen() and acquires
the writer lock.  While the thread still holds the lock, a signal
is delivered and caught.  The signal handler tries to call a function
which hasn't been bound yet.  It thus enters the dynamic linker
and tries to acquire the reader lock.  Since the writer lock is
already held, it will spin forever in the signal handler.  The
thread holding the lock won't be able to progress and release the
lock.

The solution is to block almost all signals while holding the
exclusive lock.

A similar problem could conceivably occur in the opposite order.
Namely, a thread is holding the reader lock and then a signal
handler calls dlopen() or dlclose() and spins waiting for the writer
lock.  We deal with this administratively by proclaiming that signal
handlers aren't allowed to call dlopen() or dlclose().  Actually
we don't have to proclaim a thing, since signal handlers aren't
allowed to call any system functions except those which are explicitly
permitted.

Submitted by:	Brian Fundakowski Feldman <green>
2000-07-17 17:18:13 +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
John Polstra
a0f2601e13 Eliminate unaligned accesses that occurred when relocating the
DWARF2 exception tables emitted by the compiler for C++ sources.
These tables are tightly packed, and they contain some relocated
addresses which are not well-aligned.
2000-05-22 16:31:18 +00:00
John Polstra
7dbe16fbee When a threads package registers locking methods with dllockinit(),
figure out which shared object(s) contain the the locking methods
and fully bind those objects as if they had been loaded with
LD_BIND_NOW=1.  The goal is to keep the locking methods from
requiring any lazy binding.  Otherwise infinite recursion occurs
in _rtld_bind.

This fixes the infinite recursion problem in the linuxthreads port.
2000-01-29 01:27:04 +00:00
John Polstra
5bc2f0f789 Block almost all signals in the default locking method instead of
just a few of them.  This looks like it solves the recent

  ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55

failures seen by some applications such as JDK.
2000-01-25 01:32:56 +00:00
John Polstra
9bfb1dfc29 Revamp the mechanism for enumerating and calling shared objects'
init and fini functions.  Now the code is very careful to hold no
locks when calling these functions.  Thus the dynamic linker cannot
be re-entered with a lock already held.

Remove the tolerance for recursive locking that I added in revision
1.2 of dllockinit.c.  Recursive locking shouldn't happen any more.

Mozilla and JDK users: I'd appreciate confirmation that things still
work right (or at least the same) with these changes.
2000-01-09 21:13:48 +00:00
John Polstra
3600eb76c6 Work around an assert failure in the dynamic linker's default thread
locking functions.  If an application loads a shared object with
dlopen() and the shared object has an init function which requires
lazy binding, then _rtld_bind is called when the thread is already
inside the dynamic linker.  This leads to a recursive acquisition
of the lock, which I was not expecting -- hence the assert failure.

This work-around makes the default locking functions handle recursive
locking.  It is NOT the correct fix -- that should be implemented
at the generic locking level rather than in the default locking
functions.  I will implement the correct fix in a future commit.

Since the dllockinit() interface will likely need to change, warn
about that in both the man page and the header file.
1999-12-28 04:38:17 +00:00
John Polstra
d3980376e8 Add a new function dllockinit() for registering thread locking
functions to be used by the dynamic linker.  This can be called by
threads packages at start-up time.  I will add the call to libc_r
soon.

Also add a default locking method that is used up until dllockinit()
is called.  The default method works by blocking SIGVTALRM, SIGPROF,
and SIGALRM in critical sections.  It is based on the observation
that most user-space threads packages implement thread preemption
with one of these signals (usually SIGVTALRM).

The dynamic linker has never been reentrant, but it became less
reentrant in revision 1.34 of "src/libexec/rtld-elf/rtld.c".
Starting with that revision, multiple threads each doing lazy
binding could interfere with each other.  The usual symptom was
that a symbol was falsely reported as undefined at start-up time.
It was rare but not unseen.  This commit fixes it.
1999-12-27 04:44:04 +00:00
John Polstra
926ea445fe Revamp the symbol lookup algorithm to cope better with objects
loaded separately by dlopen that have global symbols with identical
names.  Viewing each dlopened object as a DAG which is linked by its
DT_NEEDED entries in the dynamic table, the search order is as
follows:

  * If the referencing object was linked with -Bsymbolic, search it
    internally.
  * Search all dlopened DAGs containing the referencing object.
  * Search all objects loaded at program start up.
  * Search all objects which were dlopened() using the RTLD_GLOBAL
    flag (which is now supported too).

The search terminates as soon as a strong definition is found.
Lacking that, the first weak definition is used.

These rules match those of Solaris, as best I could determine them
from its vague manual pages and the results of experiments I performed.

PR:		misc/12438
1999-08-30 01:48:19 +00:00
Peter Wemm
7f3dea244c $Id$ -> $FreeBSD$ 1999-08-28 00:22:10 +00:00
Doug Rabson
e85422ad1d Add code to 'handle' R_ALPHA_NONE relocations by ignoring them. 1999-07-12 07:54:45 +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
Doug Rabson
75fd258d75 Update to the binutils-2.9.1 PLT format. 1998-09-11 18:31:55 +00:00
Doug Rabson
732b5469fe Add the r_addend of the relocation when processing GLOB_DAT relocations. 1998-09-11 18:30:55 +00:00
Doug Rabson
5e618ef5c8 Fix a cut&paste error which prevented LD_BIND_NOW from working. 1998-09-08 09:47:35 +00:00
Doug Rabson
13575fc46f Add alpha support.
Submitted by: John Birrell <jb@cimlogic.com.au> (with extra hacks by me)
Obtained from: Probably NetBSD
1998-09-04 19:03:57 +00:00