| Age | Commit message (Collapse) | Author | Lines |
|---|
|
provide the minimal level of dynamic linker-to-debugger glue needed to
let gdb find loaded libraries and load their symbols.
|
|
the code is written to pre-init the thread pointer in static linked
programs that pull in __stack_chk_fail or dynamic-linked programs that
lookup the symbol. no explicit canary is set; the canary will be
whatever happens to be in the thread structure at the offset gcc
hard-coded. this can be improved later.
|
|
note that dlerror is specified to be non-thread-safe, so no locking is
performed on the error flag or message aside from the rwlock already
held by dlopen or dlsym. if 2 invocations of dlsym are generating
errors at the same time, they could clobber each other's results, but
the resulting string, albeit corrupt, will still be null-terminated.
any use of dlerror in such a situation could not be expected to give
meaningful results anyway.
|
|
the error status is required to be sticky after failure of dlopen or
dlsym until cleared by dlerror. applications and especially libraries
should never rely on this since it is not thread-safe and subject to
race conditions, but glib does anyway.
|
|
i'm not sure that it's "correct" for dlopen to block cancellation
when calling constructors for libraries it loads, but it sure seems
like the right thing. in any case, dlopen itself needs cancellation
blocked.
|
|
|
|
|
|
this is mainly in hopes of supporting c++ (not yet possible for other
reasons) but will also help applications/libraries which use (and more
often, abuse) the gcc __attribute__((__constructor__)) feature in "C"
code.
x86_64 and arm versions of the new startup asm are untested and may
have minor problems.
|
|
these don't work (or do anything at all) but at least make it possible
to static link programs that insist on "having" dynamic loading
support...as long as they don't actually need to use it.
adding real support for dlopen/dlsym with static linking is going to
be significantly more difficult...
|
|
this issue affected programs which use global variables exported by
non-libc libraries.
|
|
even with this change, PIE will not work yet due to deficiencies in
the crt1.o startup code.
|
|
|
|
this fixes an issue using gold instead of gnu ld for linking. it also
should eliminate the need of the startup code to even load/pass the
got address to the dynamic linker.
based on patch submitted by sh4rm4 with minor cosmetic changes.
further cleanup will follow.
|
|
this only affects non-ascii symbol names, which are probably not in
use anyway..
|
|
|
|
mildly tested, seems to work
|
|
it does not work, but some configure scripts will falsely detect
support then generate programs that crash when they call dlopen.
|
|
the return address was being truncated to 32 bits, preventing the
dlsym code from determining which module contains the calling code.
|
|
this does not change behavior, but the idea is to avoid letting other
code build up between these two points, whereby the environment
variables might get used before security it checked.
|
|
|
|
the asm wrapper is needed to get the return address without
compiler-specific extensions.
|
|
|
|
|
|
|
|
|
|
instead of creating temp dso objects on the stack and moving them to
the heap if dlopen/dlsym are used, use static objects to begin with,
and just donate them to malloc if we no longer need them.
|
|
|
|
|
|
|
|
|
|
this is mostly useless for shared libs (though it could help for
prelink-like purposes); the intended use case is for adding support
for calling the dynamic linker directly to run a program, as in:
./libc.so ./a.out foo
this usage is not yet supported.
|
|
prior to this change, copy relocations for initialized pointer
variables would not reflect the relocated contents of the pointer.
|
|
|
|
|
|
|
|
deps can be null if a library has no dependencies (such as libc itself)
|
|
basically we temporarily make the library and all its dependencies
part of the global namespace but only for the duration of performing
relocations, then return them to their former state.
|
|
|
|
some of the code is not yet used, and is in preparation for dlopen
which needs to be able to handle failure loading libraries without
terminating the program.
|
|
1. search was wrongly beginning with lib itself rather than dso head
2. inconsistent resolution of function pointers for functions in plt
|
|
|
|
|
|
first, use $LD_LIBRARY_PATH unless suid. if that fails, read path from
/etc/ld-musl-$ARCH.path and fallback to a builtin default.
|
|
eventually (once dlopen exists) this behavior will be conditional on
dlopen/dlsym not being reachable.
|
|
|
|
the use of this test will be much stricter than glibc and other
typical implementations; the environment will not be honored
whatsoever unless the program is confirmed non-suid/sgid by the aux
vector the kernel passed in. no fallback to slow syscall-based
checking is used if the kernel fails to provide the information; we
simply assume the worst (suid) in this case and refuse to honor
environment.
|
|
|
|
leaving it uninitialized caused unpredictable crashes or worse due to
calling an indeterminate function pointer.
|
|
|
|
some notes:
- library search path is hard coded
- x86_64 code is untested and may not work
- dlopen/dlsym is not yet implemented
- relocations in read-only memory won't work
|
