wrong hash was being passed; just a copy/paste error. did not affect
lookups in the global namespace; this is probably why it was not
caught in testing.

previously, this usage could lead to a crash if the thread pointer was
still uninitialized, and otherwise would just cause the canary to be
zero (less secure).

based on the patches contributed by boris brezillon.

before, only the first library that failed to load or symbol that
failed to resolve was reported, and then the dynamic linker
immediately exited. when attempting to fix a library compatibility
issue, this is about the worst possible behavior. now we print all
errors as they occur and exit at the very end if errors were
encountered.

not heavily tested, but the basics are working. the basic concept is
that the dynamic linker entry point code invokes a pure-PIC (no global
accesses) C function in reloc.h to perform the early GOT relocations
needed to make the dynamic linker itself functional, then invokes
__dynlink like on other archs. since mips uses some ugly arch-specific
hacks to optimize relocating the GOT (rather than just using the
normal DT_REL[A] tables like on other archs), the dynamic linker has
been modified slightly to support calling arch-specific relocation
code in reloc.h.

most of the actual mips-specific behavior was developed by reading the
output of readelf on libc.so and simple executable files. i could not
find good reference information on which relocation types need to be
supported or their semantics, so it's possible that some legitimate
usage cases will not work yet.

changing the string printed for the dso name is not a regression; the
old code was simply using the wrong dso name (head rather than the dso
currently being relocated). this will be fixed in a later commit.

use the main program's PT_INTERP header if possible, since this is
sure to be a correct (and hopefully absolute) pathname.

if libc.a is compiled PIC for use in static PIE code, this should not
cause the dynamic linker (which still does not support static-linked
main program) to be built into libc.a.

most importantly, the name for such libs was being set from an
uninitialized buffer. also, shortname always had an initial '/'
character, making it useless for looking up already-loaded libraries
by name, and thus causing repeated searches through the library path.

major changes now:

- shortname is the base name for library lookups with no explicit
  pathname. it's initially clear for libraries loaded with an explicit
  pathname (and for the main program), but will be set if the same
  library (detected via inodes match) is later found by a search.

- exact name match is never used to identify libraries loaded with an
  explicit pathname. in this case, there's no explicit search, so we
  can just stat the file and check for inode match.

previously this was being handled the same as a library-specific,
dependency-order lookup on the next library in the global chain, which
is likely to be utterly meaningless. instead the lookup needs to be in
the global namespace, but omitting the initial portion of the global
library chain up through the calling library.

the error will propagate up and be printed to the user at program
start time; at runtime, dlopen will just fail and leave a message for
dlerror.

previously, if mprotect failed, subsequent attempts to perform
relocations would crash the program. this was resulting in an
increasing number of false bug reports on grsec systems where rwx
permission is not possible in cases where users were wrongly
attempting to use non-PIC code in shared libraries. supporting that
usage is in theory possible, but the x86_64 toolchain does not even
support textrels, and the cost of keeping around the necessary
information to handle textrels without rwx permissions is
disproportionate to the benefit (which is essentially just supporting
broken library setups on grsec machines).

also, i unified the error-out code in map_library now that there are 3
places from which munmap might have to be called.

pthread structure has been adjusted to match the glibc/GCC abi for
where the canary is stored on i386 and x86_64. it will need variants
for other archs to provide the added security of the canary's entropy,
but even without that it still works as well as the old "minimal" ssp
support. eventually such changes will be made anyway, since they are
also needed for GCC/C11 thread-local storage support (not yet
implemented).

care is taken not to attempt initializing the thread pointer unless
the program actually uses SSP (by reference to __stack_chk_fail).

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..

it does not work, but some configure scripts will falsely detect
support then generate programs that crash when they call dlopen.

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.