Some armhf gcc toolchains (built with --with-float=hard but without
--with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then
binutils rejects the UAL mnemonics for VFP unless there is an .fpu vfp
directive in the asm source.

POSIX requires pthread_join to synchronize memory on success.  The
futex wait inside __timedwait_cp cannot handle this because it's not
called in all cases.  Also, in the case of a spurious wake, tid can
become zero between the wake and when the joining thread checks it.

when determining which module an address belongs to, all function
descriptor ranges must be checked first, in case the allocated memory
falls inside another module's memory range.

dladdr itself must also check addresses against function descriptors
before doing a best-match search against the symbol table. even when
doing the latter (e.g. for code addresses obtained from mcontext_t),
also check whether the best-match was a function, and if so, replace
the result with a function descriptor address. which is the nominal
"base address" of the function and which the caller needs if it
intends to subsequently call the matching function.

since commits 2907afb8 and
6fc30c24, __dls2 is no longer called
via symbol lookup, but instead uses relative addressing that needs to
be resolved at link time. on some linker versions, and/or if
-Bsymbolic-functions is not used, the linker may leave behind a
dynamic relocation, which is not suitable for bootstrapping the
dynamic linker, if the reference to __dls2 is marked hidden but the
definition is not actually hidden. correcting the definition to use
hidden visibility fixes the problem.

the static-PIE entry point rcrt1 was likewise affected and is also
fixed by this patch.

we need access to all instructions in order for runtime selection of
atomic model to work correctly. without this patch, some versions of
gcc instruct gas to reject instructions outside the target isa level.

other archs use asm for the thread pointer load, so making that asm
volatile is sufficient to inform the compiler that it has a "side
effect" (crashing or giving the wrong result if the thread pointer was
not yet initialized) that prevents reordering. however, powerpc and
or1k have dedicated general purpose registers for the thread pointer
and did not need to use any asm to access it; instead, "local register
variables with a specified register" were used. however, there is no
specification for ordering constraints on this type of usage, and
presumably use of the thread pointer could be reordered across its
initialization.

to impose an ordering, I have added empty volatile asm blocks that
produce the "local register variable with a specified register" as
an output constraint.

this builds on commits a603a75a and
0ba35d69 to ensure that a compiler
cannot conclude that it's valid to reorder the asm to a point before
the thread pointer is set up, or to treat the inline function as if it
were declared with attribute((const)).

other archs already use volatile asm for thread pointer loading.

commit a603a75a did this for the
public pthread_self function but not the internal inline one.

strftime results are unspecified in this case, but should not invoke
undefined behaviour.

tm_wday, tm_yday, tm_mon and tm_year fields were used in signed int
arithmetic that could overflow.

based on patch by Szabolcs Nagy.

since commit c5e34dab, crt1.c has
provided a "mostly-C" implementation of the crt1 start file that
avoids the need for arch-specific symbol referencing, PIC/PIE-specific
code variants, etc. but for archs that had existing hand-written
versions, the new code was initially unused, and later only used as
the dynamic linker entry point. this commit switches all archs to
using the new code.

the code being removed was a recurring source of subtle errors, and
was still broken at least on arm, where it failed to properly align
the stack pointer before calling into C code.

a register used as an index in the memory destination of a mov
instruction was wrongly interpreted as the destination of the mov.

binary ops like ADD, AND, etc. modify the 2nd operand, not 1st.

as found and reported by Brian Mastenbrook, the expressions
400*qc_cycles and years+100 in __secs_to_tm were both subject to
integer overflow for extreme values of the input t.

this patch by Szabolcs Nagy fixes the code by switching to larger
types, and matches the original intent I had in mind when writing this
code.

the specification for these functions requires that the buffer/size
exposed to the caller be valid after any successful call to fflush or
fclose on the stream. the implementation's approach is to update them
only at flush time, but that misses the case where fflush or fclose is
called without any writes having taken place, in which case the write
flushing callback will not be called.

to fix both the observable bug and the desired invariant, setup empty
buffers at open time and fail the open operation if no memory is
available.

fdiv and fmul instructions were wrongly matched by the rules for
integer div and mul instructions, leading to incorrect conclusions
about register values being clobbered.

There is a lot which could be common between i386 and x86_64, but none
of it will be useful for any other arch. These should be useful for
all archs, however.

commit 844212d9, which did not make it
into any releases, changed nl_langinfo(CODESET) to always return
"UTF-8", even in the byte-based C locale. this was problematic because
application software was found to use the string match for "UTF-8" to
activate its own UTF-8 processing. this both undermines the byte-based
functionality of the C locale, and if mixed with with calls to the
standard multibyte functions, which happened in practice, could result
in severe mis-handling of input.

the motive for the previous change was that, to avoid widespread
compatibility problems, the string returned by nl_langinfo(CODESET)
needs to be accepted by iconv and by third-party character conversion
code. thus, the only remaining choice is "ASCII". this choice
accurately represents the intent that high bytes do not have
individual meaning in the C locale, but it does mean that iconv, when
passed nl_langinfo(CODESET) in the C locale, will produce errors in
cases where mbrtowc would have succeeded. for reference, glibc behaves
similarly in this regard, so I don't think it will be a problem.

patch by Anand Takale.

some newer binutils versions print scary warnings about protected data
because most gcc versions fail to produce the right address
references/relocations for such data that might be subject to copy
relocations. originally vis.h explicitly assigned default visibility
to all public data symbols to avoid this issue, but commit
b8dda24f removed this treatment for
stdin/out/err to work around a gcc 3.x bug, and since they don't
actually need it (because taking their addresses is not valid C).

instead, a check for the gcc 3.x bug is added to the configure check
for vis.h preinclude support; this feature will simply be disabled
when using a buggy version of gcc.

previously, __lookup_ipliteral only checked its argument against the
requested address family, so IPv4 literals passed through to
__lookup_name if the caller asked for only IPv6 results, and likewise
for IPv6 literals when the caller asked for only IPv4. this resulted
in spurious DNS lookups that reportedly even succeeded with some
nameservers.

now, __lookup_ipliteral attempts to parse its argument as both IPv4
and IPv6, and returns an error (to stop further search) rather than 0
(no results yet) if the form of the argument mismatches the requested
address family.

based on patch by Julien Ramseier.

this case is specified as a mandatory ("shall fail") error.

based on patch by Julien Ramseier.

per ISO C, CHAR_MAX, not -1, is the value used to indicate that a char
field in struct lconv is unavailable.

patch by Julien Ramseier.

The value of *size is not relevant in case of failure, but it's
better not to copy garbage from the stack into it.
(The compiler cannot see through the syscall, so optimization
was not affected by the unspecified value).

The error code of an allocating function was not checked in tre_add_tag.

the restorer function pointer provided in the kernel sigaction
structure is interpreted by the kernel as a raw code address, not a
function descriptor.

this commit moves the declarations of the __restore and __restore_rt
symbols to ksigaction.h so that arch versions of the file can override
them, and introduces a version for sh which declares them as objects
rather than functions.

an alternate solution would have been defining SA_RESTORER to 0 so
that the functions are not used, but this both requires executable
stack (since the sh kernel does not have a vdso page with permanent
restorer functions) and crashes on qemu user-level emulation.

lookup the dso an address falls in based on the loadmap and not just a
base/length. fix the main app's fake loadmap used when loaded by a
non-fdpic-aware loader so that it does not cover the whole memory
space.

function descriptor addresses are also matched for future use by
dladdr, but reverse lookups of function descriptors via dladdr have
not been implemented yet. some revisions may be needed in the future
once reclaim_gaps supports fdpic, so that function descriptors
allocated in reclaimed heap space do not get detected as belonging to
the module whose gaps they were allocated in.

previously these resolved to the code address rather than the address
of the function descriptor.

the conditions for accepting or rejecting symbols are quite
inconsistent between the different points in the dynamic linker code
where such decisions are made. this commit attempts to be at least as
correct as anything already there, but does not improve consistency.
it has been tested to correctly avoid symbols that are merely
references to functions defined in other modules, at least in simple
usage, but at some point all symbol lookup logic should be reviewed
and refactored/unified.

the entry point code supports being loaded by a loader which is not
fdpic-aware (in practice, either kernel with mmu or qemu without fdpic
support). this mostly just works, but signal handling will wrongly use
a function descriptor address as a code address if the personality is
not adjusted to fdpic.

ideally this code could be placed with sigaction so that it's not
needed except if/when a signal handler is installed. however,
personality is incorrectly maintained per-thread by the kernel, rather
than per-process, so it's necessary to correct the personality before
any threads are started. also, in order to skip the personality
syscall when an fdpic-aware loader is used, we need to be able to
detect how the program was loaded, and this information is only
readily available at the entry point.

this change is needed to be compatible with fdpic, where some of the
main application's relocations may be performed as part of the crt1
entry point. if we call init functions before passing control, these
relocations will not yet have been performed, and the init code will
potentially make use of invalid pointers.

conceptually, no code provided by the application or third-party
libraries should run before the application entry point. the
difference is not observable to programs using the crt1 we provide,
but it could come into play if custom entry point code is used, so
it's better to be doing this right anyway.

a mistaken #ifdef instead of #if caused conversion of code addresses
to function descriptors to be performed even on non-fdpic.

previously, the normal ELF library loading code was used even for
fdpic, so only the kernel-loaded dynamic linker and main app could
benefit from separate placement of segments and shared text.

this is always an error and usually results from failure to find/link
the compiler runtime library, but it could also result from
implementation errors in libc, using functions that don't (yet) exist.
either way the resulting libc.so will crash mysteriously at runtime.
the crash happens too early to produce a meaningful error, so these
crashes are very confusing to users and waste a lot of debugging time.
this commit should ensure that they do not happen.

the __fdpic_fixup code is not needed for ET_DYN executables, which
instead use reloctions, so we can omit it from the dynamic linker and
static-pie entry point and save some code size.

the C implementation of __unmapself used for potentially-nommu sh
assumed CRTJMP takes a function descriptor rather than a code address;
however, the actual dynamic linker needs a code address, and so commit
7a9669e9 changed the definition of the
macro in reloc.h. this commit puts the old macro back in a place where
it only affects __unmapself.

this is an ugly workaround and should be cleaned up at some point, but
at least it's well isolated.

at this point not all functionality is complete. the dynamic linker
itself, and main app if it is also loaded by the kernel, take
advantage of fdpic and do not need constant displacement between
segments, but additional libraries loaded by the dynamic linker follow
normal ELF semantics for mapping still. this fully works, but does not
admit shared text on nommu.

in terms of actual functional correctness, dlsym's results are
presently incorrect for function symbols, RTLD_NEXT fails to identify
the caller correctly, and dladdr fails almost entirely.

with the dynamic linker entry point working, support for static pie is
automatically included, but linking the main application as ET_DYN
(pie) probably does not make sense for fdpic anyway. ET_EXEC is
equally relocatable but more efficient at representing relocations.