the main practical purposes of this commit are to remove a huge amount
of clutter from the src/locale directory, to cut down on the length of
the $(AR) and $(LD) command lines, and to reduce the amount of space
wasted by object file headers in the static libc.a. build time may
also be reduced, though this has not been measured.

as an additional justification, if there ever were a need for the
behavior of these functions to vary by locale, it would be necessary
for the non-_l versions to call the _l versions, so that linking the
former without the latter would not be possible anyway.

this commit adds non-stub implementations of setlocale, duplocale,
newlocale, and uselocale, along with the data structures and minimal
code needed for representing the active locale on a per-thread basis
and optimizing the common case where thread-local locale settings are
not in use.

at this point, the data structures only contain what is necessary to
represent LC_CTYPE (a single flag) and LC_MESSAGES (a name for use in
finding message translation files). representation for the other
categories will be added later; the expectation is that a single
pointer will suffice for each.

for LC_CTYPE, the strings "C" and "POSIX" are treated as special; any
other string is accepted and treated as "C.UTF-8". for other
categories, any string is accepted after being truncated to a maximum
supported length (currently 15 bytes). for LC_MESSAGES, the name is
kept regardless of whether libc itself can use such a message
translation locale, since applications using catgets or gettext should
be able to use message locales libc is not aware of. for other
categories, names which are not successfully loaded as locales (which,
at present, means all names) are treated as aliases for "C". setlocale
never fails.

locale settings are not yet used anywhere, so this commit should have
no visible effects except for the contents of the string returned by
setlocale.

in some cases, these functions internally call a byte-based input or
output function before calling getwc/putwc, so they cannot rely on the
latter to set the orientation.

when the orientation of the stream was already set, fwide was
incorrectly returning its argument (the requested orientation) rather
than the actual orientation of the stream.

these functions were setting wc to point to wchar_t aliasing itself as
a "cheap" way to support null wc arguments. doing so was anything but
cheap, since even without the aliasing violation, it would limit the
compiler's ability to optimize.

making wc point to a dummy object is equally easy and does not suffer
from the above problems.

this issue caused the address of functions in shared libraries to
resolve to their PLT thunks in the main program rather than their
correct addresses. it was observed causing crashes, though the
mechanism of the crash was not thoroughly investigated. since the
issue is very subtle, it calls for some explanation:

on all well-behaved archs, GOT entries that belong to the PLT use a
special relocation type, typically called JMP_SLOT, so that the
dynamic linker can avoid having the jump destinations for the PLT
resolve to PLT thunks themselves (they also provide a definition for
the symbol, which must be used whenever the address of the function is
taken so that all DSOs see the same address).

however, the traditional mips PIC ABI lacked such a JMP_SLOT
relocation type, presumably because, due to the way PIC works, the
address of the PLT thunk was never needed and could always be ignored.

prior to commit adf94c19, the mips
version of reloc.h contained a hack that caused all symbol lookups to
be treated like JMP_SLOT, inhibiting undefined symbols from ever being
used to resolve symbolic relocations. this hack goes all the way back
to commit babf8201, when the mips
dynamic linker was first made usable.

during the recent refactoring to eliminate arch-specific relocation
processing (commit adf94c19), this
hack was overlooked and no equivalent functionality was provided in
the new code.

fixing the problem is not as simple as adding back an equivalent hack,
since there is now also a "non-PIC ABI" that can be used for the main
executable, which actually does use a PLT. the closest thing to
official documentation I could find for this ABI is nonpic.txt,
attached to Message-ID: 20080701202236.GA1534@caradoc.them.org, which
can be found in the gcc mailing list archives and elsewhere. per this
document, undefined symbols corresponding to PLT thunks have the
STO_MIPS_PLT bit set in the symbol's st_other field. thus, I have
added an arch-specific rule for mips, applied at the find_sym level
rather than the relocation level, to reject undefined symbols with the
STO_MIPS_PLT bit clear.

the previous hack of treating all mips relocations as JMP_SLOT-like,
rather than rejecting the unwanted symbols in find_sym, probably also
caused dlsym to wrongly return PLT thunks in place of the correct
address of a function under at least some conditions. this should now
be fixed, at least for global-scope symbol lookups.

due to a mistake when refactoring the error printing for the dynamic
linker (commit 7c73cacd), all messages
were suppressed and replaced by blank lines.

my old, out-of-tree release script that performed a clone rather than
using git archive checked the VERSION file to make sure that it
matched before doing a release. I believe there should be a way to do
the same with git commands (without resorting to checking out the
desired tag) but I have not yet found a way, so care should be taken
when using these targets that the correctness of the VERSION file is
not overlooked.

iptables and quagga need them to work.

the renaming was previously applied to all real versions of the
function in commit 3fa2eb2a.

it should be noted that the "real" __sysv_signal, which we do not
implement, is semantically different from signal. references to
__sysv_signal arise in code built against glibc under certain
combinations of feature test macros, and are almost surely
unintentional since the legacy sysv signal behavior has fundamental
race conditions that cannot be worked around and which make it
impossible to use safely.

these are put alongside the similar functions for __xstat, etc. in
__xstat.c to avoid bloating the number of source files.

these are mostly intended for use with dynamic linking (although they
can also be used statically with object files compiled against glibc
headers), so having them broken down into separate source files to
optimize for static linking is unlikely to be worth the cost having
more files in the source tree (which contributes to libc.a overhead,
compile time, link time, ar/linker command line size exhaustion, and
so on).

contributed by Isaac Dunham. this seems to be the last interface that
was missing for complete POSIX 2008 base + XSI coverage.

this issue affected the prioritynames and facilitynames arrays which
are only provided when requested (usually by syslogd implementations)
and which are presently defined as compound literals. the aliasing
violation seems to have been introduced as a workaround for bad
behavior by gcc's -Wwrite-strings option, but it caused compilers to
completely optimize out the contents of prioritynames and
facilitynames since, under many usage cases, the aliasing rules prove
that the contents are never accessed.

this behavior turned out to be counter-intuitive to users and in any
case it's unnecessary. optimization can be disabled explicitly using
the --disable-optimize option, or both can be achieved without any
enable/disable options by passing CFLAGS="-O0 -g".

according to the documentation in the man pages, the GNU extension
functions gethostbyaddr_r, gethostbyname_r and gethostbyname2_r are
guaranteed to set the result pointer to NULL in case of error or no
result.

this case is not even documented, but the kernel returns 0 here and it
makes sense to be consistent.

the main motivation for this change is to aid in debugging. since the
main program's entry point is also named _start, it was difficult to
set breakpoints or quickly identify which _start execution stopped in.

these are not pure syscall wrappers because they have to work around
kernel API bugs on 64-bit archs. the workarounds could probably be
made somewhat more efficient, but at the cost of more complexity. this
may be revisited later.

such separation serves multiple purposes:

- by having the common path for __tls_get_addr alone in its own
  function with a tail call to the slow case, code generation is
  greatly improved.

- by having __tls_get_addr in it own file, it can be replaced on a
  per-arch basis as needed, for optimization or ABI-specific purposes.

- by removing __tls_get_addr from __init_tls.c, a few bytes of code
  are shaved off of static binaries (which are unlikely to use this
  function unless the linker messed up).

previously, accesses to dynamic TLS had to check two conditions before
being able to use a dtv slot: (1) that the module index was within the
bounds of the current dtv size, and (2) that the dynamic tls for the
requested module index was already installed in the dtv.

this commit changes the installation strategy so that, whenever an
attempt is made to access dynamic TLS that's not yet installed in the
dtv, the dynamic TLS for all lower-index modules is also installed.
thus it provides a new invariant: if a given module index is within
the bounds of the current dtv size, we automatically know that its TLS
is installed and directly available. the requirement that the second
condition (above) be checked is eliminated.

this code is non-functional without further changes to link up the
arch-specific reloc types for tlsdesc and add asm implementations of
__tlsdesc_static and __tlsdesc_dynamic.

the logic for this loop was copied from null-terminated-string logic
in strstr without properly adapting it to work with explicit lengths.

presumably this error could result in false negatives (wrongly
comparing past the end of the needle/haystack), false positives
(stopping comparison early when the needle contains null bytes), and
crashes (from runaway reads past the end of mapped memory).

eventually this should help making dlerror thread-safe too.

this was one of the main instances of ugly code duplication: all archs
use basically the same types of relocations, but roughly equivalent
logic was duplicated for each arch to account for the different naming
and numbering of relocation types and variation in whether REL or RELA
records are used.

as an added bonus, both REL and RELA are now supported on all archs,
regardless of which is used by the standard toolchain.

processing of R_PPC_TPREL32 was ignoring the addend provided by the
RELA-style relocation and instead using the inline value as the
addend. this presumably broke dynamic-linked access to initial TLS in
cases where the addend was nonzero.

the following issues are fixed:

- R_SH_REL32 was adding the load address of the module being relocated
  to the result. this seems to have been a mistake in the original
  port, since it does not match other dynamic linker implementations
  and since adding a difference between two addresses (the symbol
  value and the relocation address) to a load address does not make
  sense.

- R_SH_TLS_DTPMOD32 was wrongly accepting an inline addend (i.e. using
  += rather than = on *reloc_addr) which makes no sense; addition is
  not an operation that's defined on module ids.

- R_SH_TLS_DTPOFF32 and R_SH_TLS_TPOFF32 were wrongly using inline
  addends rather than the RELA-provided addends.

in addition, handling of R_SH_GLOB_DAT, R_SH_JMP_SLOT, and R_SH_DIR32
are merged to all honor the addend. the first two should not need it
for correct usage generated by toolchains, but other dynamic linkers
allow addends here, and it simplifies the code anyway.

these issues were spotted while reviewing the code for the purpose of
refactoring this part of the dynamic linker. no testing was performed.

the immediate motivation is supporting TLSDESC relocations which
require allocation and thus may fail (unless we pre-allocate), but
this mechanism should also be used for throwing an error on
unsupported or invalid relocation types, and perhaps in certain cases,
for reporting when a relocation is not satisfiable.

this extension is not incompatible with the standard behavior of the
function, not expensive, and avoids requiring a replacement getopt
with full GNU extensions for a few important apps including busybox's
sed with the -i option.