src/libexec/rtld-elf/amd64, branch release/5.2.1

MFC: bandaid for R_X86_64_PC32 relocation type. Do not try to fit a 64

2003-12-14T00:45:40Z

bit peg in a 32 bit hole. Approved by: re (scottl)

Allow threading libraries to register their own locking

2003-05-29T22:58:26Z

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)

Initial pass at supporting shared libraries on amd64. There are still

2003-05-24T17:37:51Z

a few missing relocation types in amd64/reloc.c, but I have not found any of them in use yet. :-) Approved by: re (amd64/* blanket)

Remove 80386 bandaids from code repocopied from i386. rtld_start.S still

2003-04-30T21:09:06Z

todo.

No need to zero fill memory, mmapped anonymously. Kernel will

2003-03-14T21:10:13Z

return pre-zeroed pages itself. Noticed by: jake

Fix the handling of high PLT entries (> 32764) on sparc64. This requires

2002-11-18T22:08:50Z

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

Remove the nanosleep calls from the spin loops in the locking code.

2002-07-06T20:25:56Z

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

Update the asm statements to use the "+" modifier instead of

2002-06-24T23:19:18Z

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

Correct a bug in the last commit. The whole point of creating a 'done:'

2002-06-10T21:15:50Z

goto target was so the cache could be freed. So free the cache after done: rather then before done: (!) Submitted by: Gavin Atkinson

In tracking down an installation seg fault with then openoffice port

2002-06-10T18:52:31Z

Martin Blapp determined that the elf dynamic loader was at fault. In particular, the loader uses alloca() to allocate a symbol cache on the stack. Normally this would work just fine, but if the loader is called from a threaded program and the object being loaded is fairly large the alloca() can blow away the thread stack and effect other nearby thread stacks as well. My testing showed that the symbol cache can be as large as 250KBytes during the openoffice port build and install sequence. Martin was able to work around the problem by disabling the symbol cache (cache = NULL;). However, this solution is not adequate for commit because it can cause an enormous cpu burden for applications which do a lot of dynamic loading (e.g. like konqueror). The solution is to use anonymous mmap() to temporarily allocate space to hold the symbol cache. In testing I found that replacing the alloca() with mmap() has no observable degredation in performance. It should be noted that this bug does not necessarily cause an immediate crash but can instead result in long term corruption and instability in applications that load modules from threads. The bug is almost certainly responsible for some of the instabilities found in konqueror, for example, and possibly netscape too. Sleuthing work by: Martin Blapp X-MFC after: Before or after the 4.6 release depending on the release engineers