new behavior can be summarized as:
inputs that parse completely as a decimal number are treated as one,
and rejected only if the result is out of 16-bit range.
inputs that do not parse as a decimal number (where strtoul leaves
anything left over in the input) are searched in /etc/services.

also cleanup cruft related to the issue

not tested on mips and arm; they may still be broken. x86_64 should be
ok now.

this is useful when the underlying gcc is already a wrapper, which is
the case at least on some uclibc-based system images. it's also useful
for running an older/newer/nondefault version of gcc.

issue reported/requested by Justin Cormack

patch by Justin Cormack, with slight modification

the linux O_PATH mode provides the necessary semantics for both the
O_SEARCH and O_EXEC modes defined and required by POSIX 2008.

contributed by nsz

this could cause major bugs, and warrants a fix release right away.

no problems were detected so far, but the constraints seem to have
been invalid just like the mips ones.

it was determined in discussion that these kind of limits are not
sufficient to protect single-threaded servers against denial of
service attacks from maliciously large round counts. the time scales
simply vary too much; many users will want login passwords with rounds
counts on a scale that gives decisecond latency, while highly loaded
webservers will need millisecond latency or shorter.

still some limit is left in place; the idea is not to protect against
attacks, but to avoid the runtime of a single call to crypt being, for
all practical purposes, infinite, so that configuration errors can be
caught and fixed without bringing down whole systems. these limits are
very high, on the order of minute-long runtimes for modest systems.

these fixes were already made to the normal syscall asm but not the
cancellation point version.

if same register is used for input/output, the compiler must be told.
otherwise is generates random junk code that clobbers the result. in
pure syscall-wrapper functions, nothing went wrong, but in more
complex functions where register allocation is non-trivial, things
broke badly.

with this patch, the malloc in libc.so built with -Os is nearly the
same speed as the one built with -O3. thus it solves the performance
regression that resulted from removing the forced -O3 when building
libc.so; now libc.so can be both small and fast.

I originally added -O3 for shared libraries to counteract very bad
behavior by GCC when building PIC code: it insists on reloading the
GOT register in static functions that need it, even if the address of
the function is never leaked from the translation unit and all local
callers of the function have already loaded the GOT register. this
measurably degrades performance in a few key areas like malloc. the
inlining done at -O3 avoids the issue, but that's really not a good
reason for overriding the user's choice of optimization level.

vfork is implemented as the fork syscall (with no atfork handlers run)
on archs where it is not available, so this change does not introduce
any change in behavior or regression for such archs.

I'm not 100% sure that Linux's O_PATH meets the POSIX requirements for
O_SEARCH, but it seems very close if not perfect. and old kernels
ignore it, so O_SEARCH will still work as desired as long as the
caller has read permissions to the directory.

by using the "ir" constraint (immediate or register) and the carefully
constructed instruction addu $2,$0,%2 which can take either an
immediate or a register for %2, the new inline asm admits maximal
optimization with no register spillage to the stack when the compiler
successfully performs constant propagration, but still works by
allocating a register when the syscall number cannot be recognized as
a constant. in the case of syscalls with 0-3 arguments it barely
matters, but for 4-argument syscalls, using an immediate for the
syscall number avoids creating a stack frame for the syscall wrapper
function.

all past and current kernel versions have done so, but there seems to
be no reason it's necessary and the sentiment from everyone I've asked
has been that we should not rely on it. instead, use r7 (an argument
register) which will necessarily be preserved upon syscall restart.
however this only works for 0-3 argument syscalls, and we have to
resort to the function call for 4-argument syscalls.

for the sake of simplicity, I've only used rep movsb rather than
breaking up the copy for using rep movsd/q. on all modern cpus, this
seems to be fine, but if there are performance problems, there might
be a need to go back and add support for rep movsd/q.

before restrict was added, memove called memcpy for forward copies and
used a byte-at-a-time loop for reverse copies. this was changed to
avoid invoking UB now that memcpy has an undefined copying order,
making memmove considerably slower.

performance is still rather bad, so I'll be adding asm soon.

this should both fix the issue with ARM needing -lgcc_eh (although
that's really a bug in the libgcc build process that's causing
considerable bloat, which should be fixed) and make it easier to build
musl using clang/llvm in place of gcc. unfortunately I don't know a
good way to detect and support pcc's -lpcc since it's not in pcc's
default library search path...

no syscalls actually use that many arguments; the issue is that some
syscalls with 64-bit arguments have them ordered badly so that
breaking them into aligned 32-bit half-arguments wastes slots with
padding, and a 7th slot is needed for the last argument.

most pure-syscall-wrapper functions compile to the smallest/simplest
code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail
call to __syscall_ret).

this drastically reduces the size of some functions which are purely
syscall wrappers.

disabled for clang due to known bugs satisfying register constraints.

this code was using $10 to save the syscall number, but $10 is not
necessarily preserved by the kernel across syscalls. only mattered for
syscalls that got interrupted by a signal and restarted. as far as i
can tell, $25 is preserved by the kernel across syscalls.