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.

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.