(and that is for now being worked around by a binutils patch).
The rtld code tested &_DYNAMIC against 0 to see whether rtld itself
was built as PIC or not. While the sparc64 MD code did not rely
on the preset value of the GOT slot for _DYNAMIC any more due
to previous binutils changes, it still used to not be 0, so
that this check did work. The new binutils do however initialize
this slot with 0. As a consequence, rtld would not properly initialize
itself and crash.
Fix that by introducing a new macro, RTLD_IS_DYNAMIC, to take the role
of this test. For sparc64, it is implemented using the rtld_dynamic()
code that was already there. If an architecture does not provide its
own implementation, we default to the old check.
While being there, mark _DYNAMIC as a weak symbol in the sparc64
rtld_start.S. This is needed in the LDSCRIPT case, which is however
not currently supported for want of an actual ldscript.
Sanity checked with md5 on alpha, amd64, i386 and ia64.
eg:
[foo]
...
matches any executable 'foo'
[/usr/bin/foo/]
...
matches any executable under the directory /usr/bin/foo/
Exact matches continue to function as before.
PR: bin/66769
Submitted-by: Dan Nelson
with the correct alignment. This is important because this calls to
library static constructors are made from here. The bug in the old crt*.s
files hid this because in this case, two wrongs do indeed make a right.
Also, call _rtld_bind() with the correct alignment, because it calls back
into the pthread library locking functions. If things happen just
the wrong way, we get a SIG10 due to the broken stack alignment.
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
(libmap available) and 1 for failure. Assign this return to the
global 'libmap_disable' variable in rtld.c.
This totally prevents any libmap functions from being called after
lm_init() if no config file is present.
rtld. When _DYNAMIC is referenced normally from C the global offset
table is used implicitly, but newer versions of binutils don't initialize
it statically in the binary, so this doesn't work until rtld is relocated,
which _DYNAMIC is needed for... So, as on other systems with the same
problem, we disassemble a call instruction to _DYNAMIC in order to get
its address.
Setting the LD_DUMP_REL_PRE or LD_DUMP_REL_POST environment variables
cause rtld-elf to output a table of all relocations.
This is useful for debugging.
While I'm here:
- Let lm_add() call strdup() on its own behalf.
- Use a temporary pointer when parsing constraints; only set the
constraint pointer on a totally successful match.
PR: bin/52783
Submitted by: David P. Reese Jr. <daver@gomerbud.com>
Approved by: re (rwatson)
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)
DT_NEEDED links is not flexible enough for cases where dynamically
loaded modules form a dependency cycle.
This should fix an infinite recursion problem encountered by Yahoo.
Approved by: re (jhb)
This is an optional feature, disabled by default.
This will be useful to people testing the various POSIX threading
libraries under -CURRENT but can easily serve other needs.
objects.
Programs such as sshd depend on two pointers to the same function being
equal in a given process. However, the current ia64 implementation
ensures that they're equal when both the pointers are instantiated in
the same ELF object. The attached patch ensures that they're equal
irrespective of where they're instantiated.
Reviewed by marcel@ (mentor) and kan@
Introduce a new unlink_object() function and call it in
unload_object() instead. Removing the object in unref_dag() is
too early, rtld calls _fini() function after that and shared
objects might fail resolve their own symbols.
Introdice RTLD_SELF special handle and properly process it within
dlsym() and dlinfo() functions.
The intention is to improve our compatibility with Solaris and
to make a Java port easier.
Partially submitted by: phantom
associated lists:
remove RTLD_GLOBAL objects from global objects list;
remove the parent object from dldags list of its children.
Previosly we were doing that only to the top-level object OF the DAG
being unloaded and all its dependencies were ignored, leading to
mysterious crashes later.
Submitted by: peter (partially)
skipping read-only pages, which can result in valuable non-text-related
data not getting dumped, the ELF loader and the dynamic loader now mark
read-only text pages NOCORE and the coredump code only checks (primarily) for
complete inaccessibility of the page or NOCORE being set.
Certain applications which map large amounts of read-only data will
produce much larger cores. A new sysctl has been added,
debug.elf_legacy_coredump, which will revert to the old behavior.
This commit represents collaborative work by all parties involved.
The PR contains a program demonstrating the problem.
PR: kern/45994
Submitted by: "Peter Edwards" <pmedwards@eircom.net>, Archie Cobbs <archie@dellroad.org>
Reviewed by: jdp, dillon
MFC after: 7 days
before referencing object's DAG. This makes it possible for
C++ exceptions to work across shared libraries and brings
us closer to the search order used by Solaris/Linux.
Reviewed by: jdp
Approved by: obrien
MFC after: 1 month
even if there was no error occured (when trying to dlopen(3) object that
already linked into executable which does dlopen(3) call). This is more
proper fix for `ldd /usr/lib/libc.so' problem, because the new behaviour
conforms to documentation.
Remove workaround from ldd.c (rev.1.32).
PR: 35099
Submitted by: Nathan Hawkins <utsl@quic.net>
MFC after: 1 week
for the DT_IA64_PLT_RESERVE dynamic table entry. When a shared object
does not have any PLT relocations, the linker apparently doesn't find
it necessary to actually reserve the space for the BOR (Bind On
Reference) entries as pointed to by the DTE. As a result, relocatable
data in the PLT was overwritten, causing some unexpected control flow
with annoyingly predictable outcome: coredump.
To reproduce:
% echo 'int main() { return 0; }' > foo.c
% cc -o foo foo.c -lxpg4
objects' reference counts. This function is called by the atexit
mechanism at program shutdown. I don't think the locking is necessary
here. It caused OpenOffice builds to hang more often than not.
Credit to Martin Blapp and Matt Dillon for helping to diagnose this
problem and for testing the fix.
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
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
Untested (testing request went unanswered), but sparc64 is not expected to
cause problems. IA64 is not expected to cause problems but the patch was
slightly more complex so the possibility exists.
Approved by: jdp
goto target was so the cache could be freed. So free the cache after
done: rather then before done: (!)
Submitted by: Gavin Atkinson <gavin@ury.york.ac.uk>
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 <mb@imp.ch>
X-MFC after: Before or after the 4.6 release depending on the release engineers
o Set st_shndx for sym_zero to SHN_UNDEF instead of SHN_ABS.
This gives us something to reliably test against.
o For weak references to undefined sysmbols (as indicated by
having st_shndx equals SHN_UNDEF) in the context of OPDs,
the address of the OPD is to be zero, not the address of
the function it contains.
o For weak references to undefined symbols in all other cases
(only DIR64LSB at this time), the actual relocated value is
to be zero, not the value prior to relocating.
Roughly speaking, weak references to undefined symbols are no-ops.
Tested on: i386, ia64
relocation identifies the symbol to which we need to bind. This
solves a problem seen on ia64 where the symbol hash table does not
contain local symbols and thus resulted in unresolved symbols.
Tested on: alpha, i386, ia64
objects were not being correctly set to zero. Instead, the function
descriptor pointer was set to the load address of the .so object. This
caused gcc generated binaries to segfault on exit when crtbegin.asm's
_fini code tested the __cxa_finalize() function pointer for zero.
This is a bit of a hack because of a problem nearby workaround for
find_symdef and its quirks (failures) for local symbols. This still
needs to be fixed.
