src-test2/libexec/rtld-elf/amd64, branch stable/4

This commit was manufactured by cvs2svn to create branch 'RELENG_4'.

2000-03-13T04:59:44Z

When a threads package registers locking methods with dllockinit(),

2000-01-29T01:27:04Z

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.

Block almost all signals in the default locking method instead of

2000-01-25T01:32:56Z

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.

Revamp the mechanism for enumerating and calling shared objects'

2000-01-09T21:13:48Z

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.

Work around an assert failure in the dynamic linker's default thread

1999-12-28T04:38:17Z

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.

Add a new function dllockinit() for registering thread locking

1999-12-27T04:44:04Z

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.

$Id$ -> $FreeBSD$

1999-08-28T00:22:10Z

Fix a serious performance bug for large programs on the Alpha,

1999-06-25T02:53:59Z

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

Eliminate all machine-dependent code from the main source body and

1999-04-09T00:28:43Z

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.

Add alpha support.

1998-09-04T19:03:57Z

Submitted by: John Birrell (with extra hacks by me) Obtained from: Probably NetBSD