three ABIs are supported: the default with 68881 80-bit fpu format and
results returned in floating point registers, softfloat-only with the
same format, and coldfire fpu with IEEE single/double only. only the
first is tested at all, and only under qemu which has fpu emulation
bugs.

basic functionality smoke tests have been performed for the most
common arch-specific breakage via libc-test and qemu user-level
emulation. some sysvipc failures remain, but are shared with other big
endian archs and will be fixed separately.

we have always bound symbols at libc.so link time rather than runtime
to minimize startup-time relocations and overhead of calls through the
PLT, and possibly also to preclude interposition that would not work
correctly anyway if allowed. historically, binding at link-time was
also necessary for the dynamic linker to work, but the dynamic linker
bootstrap overhaul in commit f3ddd173
made it unnecessary.

our use of -Bsymbolic-functions, rather than -Bsymbolic, was chosen
because the latter is incompatible with public global data; it makes
it incompatible with copy relocations in the main program. however,
not all global data needs to be public. by using --dynamic-list
instead with an explicit list, we can reduce the number of symbolic
relocations left for runtime.

this change will also allow us to permit interposition of specific
functions (e.g. the allocator) if/when we want to, by adding them to
the dynamic list.

Maintainer's note: at one point, -lcompiler_rt apparently worked, and
may still work and be preferable if one has manually installed the
library in a public lib directory. but with current versions of clang,
the full pathname to the library file is needed. the original patch
removed the -lcompiler_rt check; I have left it in place in case there
are users depending on it, and since, when it does work, it's
preferable so as not to code a dependency on the specific compiler
version and paths in config.mak.

neither current compilers nor linkers treat protected visibility the
way I expected, as having fixed source-level semantics rather than
being dependent on target-specific ABI details, and change seems
unlikely. while the use here does not actually depend on the specific
semantics, at least some versions of some linkers, especially lld,
refuse to allow linking to a libc.so where the symbols have protected
visibility. this cannot be detected at configure-time because linking
libc.so itself works fine, and because even if we could test linking
an application against libc.so successfully, we could not justifiably
assume that the same linker used to link libc.so would also be used
later to link applications.

disable the vis.h hack by default at the configure level, but add an
explicit "auto" option to request the old configure-time detection
rather than just removing it. this leaves it easy to evaluate whether
it actually resulted in significant size or performance benefits while
ensuring that out-of-the-box builds are not unlinkable for some users.

fortunately, preliminary evaluation suggests that at least x86_64,
arm, and aarch64 don't suffer at all from the change, and impact on
other archs is low. if low is not low enough, it should not be hard to
analyze where the significant PLT call ABI costs are present and
mitigate them without the hack.

all assembly is now thumb2-compatible. on existing targets this is at
best a size optimization, but it will also facilitate porting to
thumb2-isa-only arm variants.

the gnu config.sub script recognizes several mipsisa64* cpu types
that musl supports as mips64 targets.

The --build flag is listed in two case statement entries in configure,
which causes the second entry to be ignored. This patch removes it
from the first entry.
Signed-off-by: NMichael LeMay <michael.lemay@intel.com>

the standard configure interface, which our configure script tries to
implement, identifies cross compiling (build != host) and searches for
the properly-prefixed cross tools. our script was not doing that,
forcing users to explicitly provide either CC or a CROSS_COMPILE tool
prefix, and the more common choice, just providing CC, was incomplete
because the Makefile would still invoke the native ar and ranlib
programs. this happened to work when building on ELF-based systems
with GNU binutils, but could easily fail when cross-compiling from
dissimilar systems.

like before, and like the standard configure behavior, an explicit CC
or CROSS_COMPILE variable on the command line or in the environment
overrides the automatic prefixing.

based on patch submitted by Jaydeep Patil, with minor changes.

mips32r6 and mips64r6 are actually new isas at both the asm source and
opcode levels (pre-r6 code cannot run on r6) and thus need to be
treated as a new subarch. the following changes are made, some of
which yield code generation improvements for non-r6 targets too:

- add subarch logic in configure script and reloc.h files for dynamic
  linker name.

- suppress use of .set mips2 asm directives (used to allow mips2
  atomic instructions on baseline mips1 builds; the kernel has to
  emulate them on mips1) except when actually needed. they cause wrong
  instruction encodings on r6, and pessimize inlining on at least some
  compilers.

- only hard-code sync instruction encoding on mips1.

- use "ZC" constraint instead of "m" constraint for llsc memory
  operands on r6, where the ll/sc instructions no longer accept full
  16-bit offsets.

- only hard-code rdhwr instruction encoding with .word on targets
  (pre-r2) where it may need trap-and-emulate by the kernel.
  otherwise, just use the instruction mnemonic, and allow an arbitrary
  destination register to be used.

the SPE ABI may be compatible with soft-float, but actually making it
work requires some additional work, so for now it's best to make sure
broken builds don't happen.

Some PowerPC CPUs (e.g. Freescale MPC85xx) have a completely different
instruction set for floating point operations (SPE).
Executing regular PowerPC floating point instructions results in
"Illegal instruction" errors.

Make it possible to run these devices in soft-float mode.

patch by Mahesh Bodapati and Jaydeep Patil of Imagination
Technologies.

the nt32 and nt64 archs will be provided by the midipix project for
building musl on top of its posix-like syscall layer for windows. at
present the needed arch files are in a separate repository, but having
the tuple matching in the upstream configure script should make it
possible to overlay the arch files without needing any further
patching.

commit e4355bd6 moved the math asm
from external source files to inline asm, but unfortunately, all
current releases of clang use the wrong inline asm constraint codes
for float and double ("w" and "P" instead of "t" and "w",
respectively). this patch adds detection for the bug in configure,
and, for now, just disables the affected asm on broken clang versions.

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.

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.

this sets the stage for the first phase of the bits deduplication.
bits headers which are identical for "most" archs will be moved to
arch/generic/bits.

this test does not include anything, so the -I options are not useful
and are just a maintenance burden if paths change.

now that .lo and .o files differ only by whether -fPIC is passed (and
no longer at the source level based on the SHARED macro), it's
possible to use the same object files for both static and shared libc
when the compiler would produce PIC for the static files anyway. this
happens if the user has included -fPIC in their CFLAGS or if the
compiler has been configured to produce PIE by default.

we use the .lo files for both, and still append -fPIC to the CFLAGS,
rather than using the .o files so that libc.so does not break
catastrophically if the user later removes -fPIC from CFLAGS in
config.mak or on the make command line. this also ensures that we get
full -fPIC in case -fpic, -fPIE, or some other lesser-PIC option was
passed in CFLAGS.

commit 2f853dd6 failed to change the
test for -include vis.h support to use $srcdir, so vis.h was always
disabled by configure for out-of-tree builds.

this change adds support for building musl outside of the source
tree. the implementation is similar to autotools where running
configure in a different directory creates config.mak in the current
working directory and symlinks the makefile, which contains the
logic for creating all necessary directories and resolving paths
relative to the source directory.

to support both in-tree and out-of-tree builds with implicit make
rules, all object files are now placed into a separate directory.

this allowing the linker to drop certain weak definitions that are
only used as dummies for static linking. they could be eliminated for
shared library builds using the preprocessor instead, but we are
trying to transition to using the same object files for shared and
static libc, so a link-time solution is preferable.

based on patch by Denys Vlasenko. sorting sections and common data
symbols by alignment acts as an approximation for optimal packing,
which the linker does not actually support.

based on patch by Denys Vlasenko. the original intent for using these
options was to enable linking optimizations. these are immediately
available for static linking applications to libc.a, and will also be
used for linking libc.so in a subsequent commit.

in addition to the original motives, this change works around a whole
class of toolchain bugs where the compiler generates relative address
expressions using a weak symbol and the assembler "optimizes out" the
relocation which should result by using the weak definition. (see gas
pr 18561 and gcc pr 66609, 68178, etc. for examples.) by having
different functions and data objects in their own sections, all
relative address expressions are cross-section and thus cannot be
resolved to constants until link time. this allows us to retain
support for affected compiler/assembler versions without invasive
and fragile source-level workarounds.

this way, overriding these variables on the make command line (or just
re-passing the originally-passed values when invoking make) won't
suppress use of the flags added by configure.

the option to suppress executable stack tagging was placed in CFLAGS,
which is treated as optional and overridable by the build system. if a
user replaces CFLAGS after configure has run, it could get lost,
resulting in a libc.so that's flagged as needing executable stack,
which would cause the kernel to map the initial stack as executable.

move -Wa,--noexecstack to CFLAGS_C99FSE, the make variable used for
mandatory compiler options.

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.

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.

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.

with this commit it should be possible to produce a working
static-linked fdpic libc and application binaries for sh.

the changes in reloc.h are largely unused at this point since dynamic
linking is not supported, but the CRTJMP macro is used one place
outside of dynamic linking, in __unmapself.

Some functions implemented in asm need to use EBP for purposes other
than acting as a frame pointer. (Notably, it is used for the 6th
argument to syscalls with 6 arguments.) Without frame pointers, GDB
can only show backtraces if it gets CFI information from a
.debug_frame or .eh_frame ELF section.

Rather than littering our asm with ugly .cfi directives, use an awk
script to insert them in the right places during the build process, so
GDB can keep track of where the current stack frame is relative to the
stack pointer. This means GDB can produce beautiful stack traces at
any given point when single-stepping through asm functions.

Additionally, when registers are saved on the stack and later
overwritten, emit ..cfi directives so GDB will know where they were
saved relative to the stack pointer. This way, when you look back up
the stack from within an asm function, you can still reliably print
the values of local variables in the caller.

If this awk script were to understand every possible wild and crazy
contortion that an asm programmer can do with the stack and registers,
and always emit the exact ..cfi directives needed for GDB to know what
the register values were in the preceding stack frame, it would
necessarily be as complex as a full x86 emulator. That way lies
madness.

Hence, we assume that the stack pointer will _only_ ever be adjusted
using push/pop or else add/sub with a constant. We do not attempt to
detect every possible way that a register value could be saved for
later use, just the simple and common ways.

Thanks to Szabolcs Nagy for suggesting numerous improvements to this
code.