the dynamic linker was found to hang when used as the PT_INTERP, but
not when invoked as a command. the mechanism of this failure was not
determined, but the cause is clear:

commit 5552ce52 removed the SHARED
macro, but arch/sh/crt_arch.h is still using it to choose the right
form of the crt/ldso entry point code. moving the forced definition
from rcrt1.c to dlstart.c restores the old behavior. eventually the
logic should be changed to fully remove the SHARED macro or at least
rename it to something more reasonable.

commit 80fbaac4 broke all soft-float
archs, where gcc defines __GCC_IEC_559==0 because rounding modes and
exception flags are not supported. for now, just check for
__FAST_MATH__ as an indication of broken float. this won't detect all
possible misconfigurations but it probably catches the most common
one.

commit 2f853dd6 moved the error
handling for $(ARCH) not being set such that it applied to all
targets, including clean and distclean. previously these targets
worked even in an unconfigured tree. to restore the old behavior, make
most of the makefile body conditional on $(ARCH) being set/non-empty
and produce the error via a fake "all" target in the conditional
branch for the case where $(ARCH) is empty.

prior to commit 2f853dd6 which
overhauled the makefile for out-of-tree builds, crt/*.c files were
replaceable by crt/$(ARCH)/*.s, and top-level ldso/ did not exist (its
files were under src/ldso). since then, crti.o and crtn.o have been
hard-coded as arch-specific, but none of the other files in crt/ or
ldso/ were replaceable at all.

in preparation for easy integration with midipix, which has a port of
musl to windows, it needs to be possible to override the ELF-specific
code in these files. making the same arch-replacements system work
throughout the whole source tree also improves consistency and removes
the need for some file-specific rules (crti.o and crtn.o) in the
makefile.

the reference implementation clamps rounds to [1000,999999999]. we
further limited rounds to at most 9999999 as a defense against extreme
run times, but wrongly clamped instead of treating out-of-bounds
values as an error, thereby producing implementation-specific hash
results. fixing this should not break anything since values of rounds
this high are not useful anyway.

like fputs (see commit 10a17dfb), the
message printing code for getopt assumed that fwrite only returns 0 on
failure, but it can also happen on success if the total length to be
written is zero. programs with zero-length argv[0] were affected.

commit 500c6886 introduced this
problem in getopt by fixing the fwrite behavior to conform to the
requirements of ISO C. previously the wrong expectations of the getopt
code were met by the fwrite implementation.

internally, the idiom of passing nmemb=1 to fwrite and interpreting
the return value of fwrite (which is necessarily 0 or 1) as
failure/success is fairly widely used. this is not correct, however,
when the size argument is unknown and may be zero, since C requires
fwrite to return 0 in that special case. previously fwrite always
returned nmemb on success, but this was changed for conformance with
ISO C by commit 500c6886.

some software simply uses static_assert if the macro is defined, and
this breaks if the compiler does not recognize the _Static_assert
keyword used to define it.

commit 378f8cb5 added these functions
(as stubs) but left them without declarations. this broke some
autoconf based software that detected linkability of the symbols but
didn't check for a declaration.

when the size argument was zero but nmemb was nonzero, these functions
were returning nmemb, despite no data having been written.
conceptually this is not wrong, but the standard requires a return
value of zero in this case.

as specified, the int argument providing the character to write is
converted to type unsigned char. for the actual write to buffer,
conversion happened implicitly via the assignment operator; however,
the logic to check whether the argument was a newline used the
original int value. thus usage such as putchar('\n'+0x100) failed to
produce a flush.

when a write error occurred while flushing output due to a newline,
fwrite falsely reported all bytes up to and including the newline as
successfully written. in general, due to buffering such "spurious
success" returns are acceptable for stdio; however for line-buffered
mode it was subtly wrong. errors were still visible via ferror() or as
a short-write return if there was more data past the newline that
should have been written, but since the contract for line-buffered
mode is that everything up through the newline be written out
immediately, a discrepency was observable in the actual file contents.

the workaround was for a bug that botched .gpword references to local
labels, applying a nonsensical random offset of -0x4000 to them.

this reverses commit 5e396fb9 and a
removes a similar hack that was added to syscall_cp.s in the later
commit 756c8af8. it turns out one
additional instance of the same idiom, the GETFUNCSYM macro in
arch/mips/reloc.h, was still affected by the assembler bug and does
not admit an easy workaround without making assumptions about how the
macro is used. the previous workarounds made static linking work but
left the early-stage dynamic linker broken and thus had limited
usefulness.

instead, affected users (using binutils versions older than 2.20) will
need to fix the bug on the binutils side; the trivial patch is commit
453f5985b13e35161984bf1bf657bbab11515aa4 in the binutils-gdb
repository.

the old __cp_cancel code path loaded the address of __cancel from the
GOT using the $gp register, which happened to be set to point to the
correct GOT by the calling C function, but there is no ABI requirement
that this happen. instead, go the roundabout way and compute the
address of __cancel via pc-relative and gp-relative addressing
starting with a fake return address generated by a bal instruction,
which is the same trick crt1 uses to bootstrap.

not only is pthread_kill expensive in this case; it also breaks
testing under qemu app-level emulation.

add aarch64 and or1k archs, upgrade sh from experimental, and note
that sh now supports the FDPIC ABI.

the old advice on compiler versions was outdated and more specific
than made sense. presence of compiler bugs varies a lot by arch, so
it's hard to make any good recommendations beyond "recent". if we want
to document specific known-good/bad compiler versions, a much larger
section in the documentation than what's appropriate for the INSTALL
file would be needed.

the linux man page specifies malloc_usable_size(0) to return 0 and
this is the semantics other implementations follow (jemalloc).
reported by Alexander Monakov.

10k elements stack is increased to 1000k, otherwise tnfa creation fails
for reasonable sized patterns: a single literal char can add 7 elements
to this stack, so regcomp of an 1500 char long pattern (with only litral
chars) fails with REG_ESPACE. (the new limit allows about < 150k chars,
this arbitrary limit allows most command line regex usage.)

ideally there would be no upper bound: regcomp dynamically reallocates
this buffer, every reallocation checks for allocation failure and at
the end this stack is freed so there is no reason for special bound.
however that may have unwanted effect on regcomp and regexec runtime
so this is a conservative change.

"Q" input constraint was used for the written object, instead of "=Q"
output constraint.  this should not cause problems because "memory"
is on the clobber list, but "=Q" better documents the intent and more
consistent with the actual asm code.

this changes the generated code, because different registers are used,
but other than the register names nothing should change.

previous work overhauling the dynamic linker made it so that linking
libc with -Bsymbolic-functions was no longer mandatory, but the
configure logic that forced --disable-shared when ld failed to accept
the option was left in place.

this commit removes the hard-coded -Bsymbolic-functions from the
Makefile and changes the configure test to one that simply adds it to
the auto-detected LDFLAGS on success.

GDB is looking for a pointer to the ldso debug info in the data of the
..rld_map section.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>

These are undefined escape sequences by the standard, but often
used in sed scripts.

The goto logic was hard to follow and modify. This is
in preparation for the BRE \+ and \? support.

The standard does not define semantics for \| in BRE, but some code
depends on it meaning alternation. Empty alternative expression is
allowed to be consistent with ERE.

Based on a patch by Rob Landley.

Previously repetitions were accepted after empty expressions like
in (*|?)|{2}, but in BRE the handling of * and \{\} were not
consistent: they were accepted as literals in some cases and
repetitions in others.

It is better to treat repetitions after an empty expression as an
error (this is allowed by the standard, and glibc mostly does the
same). This is hard to do consistently with the current logic so
the new rule is:

Reject repetitions after empty expressions, except after assertions
^*, $? and empty groups ()+ and never treat them as literals.

Empty alternation (|a) is undefined by the standard, but it can be
useful so that should be accepted.

This should not change the meaning of the code, just make the intent
clearer: advancing position is tied to adding a new literal.

this file's .data section was not aligned, and just happened to get
the correct alignment with past builds. it's likely that the move of
atomic.s from arch/arm/src to src/thread/arm caused the change in
alignment, which broke the atomic and thread-pointer access fragments
on actual armv5 hardware.

commit d56460c9 introduced this bug by
setting up the tls module chain incorrectly when the main app has tls.
the singly-linked list head pointer was setup correctly, but the tail
pointer was not, so the first attempt to append to the list (for a
shared library with tls) would treat the list as empty and effectively
removed the main app from the list. this left all tls module id
numbers off-by-one.

this bug did not appear in any released versions.

search is only performed if the search or domain keyword is used in
resolv.conf and the queried name has fewer than ndots dots. there is
no default domain and names with >=ndots dots are never subjected to
search; failure in the root scope is final.

the (non-POSIX) res_search API presently does not honor search. this
may be added at some point in the future if needed.

resolv.conf is now parsed twice, at two different layers of the code
involved. this will be fixed in a subsequent patch.

rcode of 3 (NxDomain) was treated as a hard EAI_NONAME failure, but it
should instead return 0 (no results) so the caller can continue
searching. this will be important for adding search domain support.
the top-level caller will automatically return EAI_NONAME if there are
zero results at the end.

also, the case where rcode is 0 (success) but there are no results was
not handled. this happens when the domain exists but there are no A or
AAAA records for it. in this case a hard EAI_NONAME should be imposed
to inhibit further search, since the name was defined and just does
not have any address associated with it. previously a misleading hard
failure of EAI_FAIL was reported.

this change is made in preparation for adding search domains, for
which higher-level code will need to parse resolv.conf. simply parsing
it twice for each lookup would be one reasonable option, but the
existing parser code was buggy anyway, which suggested to me that it's
a bad idea to have two variants of this code in two different places.

the old code in res_msend potentially misinterpreted overly long lines
in resolv.conf, and stopped parsing after it found 3 nameservers, even
if there were relevant options left to be parsed later in the file.