With the exception of a fenv implementation, the port is fully featured.
The port has been tested in or1ksim, the golden reference functional
simulator for OpenRISC 1000.
It passes all libc-test tests (except the math tests that
requires a fenv implementation).
The port assumes an or1k implementation that has support for
atomic instructions (l.lwa/l.swa).
Although it passes all the libc-test tests, the port is still
in an experimental state, and has yet experienced very little
'real-world' use.
previously we detected this bug in configure and issued advice for a
workaround, but this turned out not to work. since then gcc 4.9.0 has
appeared in several distributions, and now 4.9.1 has been released
without a fix despite this being a wrong code generation bug which is
supposed to be a release-blocker, per gcc policy.
since the scope of the bug seems to affect only data objects (rather
than functions) whose definitions are overridable, and there are only
a very small number of these in musl, I am just changing them from
const to volatile for the time being. simply removing the const would
be sufficient to make gcc 4.9.1 work (the non-const case was
inadvertently fixed as part of another change in gcc), and this would
also be sufficient with 4.9.0 if we forced -O0 on the affected files
or on the whole build. however it's cleaner to just remove all the
broken compiler detection and use volatile, which will ensure that
they are never constant-folded. the quality of a non-broken compiler's
output should not be affected except for the fact that these objects
are no longer const and thus possibly add a few bytes to data/bss.
this change can be reconsidered and possibly reverted at some point in
the future when the broken gcc versions are no longer relevant.
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".
previously, a warning was issued in this case no matter what, even if
--disable-shared was used. now, the default for --enable-shared is
changed from "yes" to "auto", and the warning is issued by default,
but becomes an error if --enable-shared is used, and the test is
suppressed completely if --disable-shared is used.
this is gcc bug #61144. the broken compiler is detected, but the user
must manually work around it. this is partly to avoid complex logic
for adding workaround CFLAGS and attempting to recheck with them, and
partly for the sake of letting the user know the compiler is broken
(since the workaround will result in less-efficient code production).
some refactoring was also needed to move the check for gcc outside of
the check for whether to build the compiler wrapper.
without this, broken choices of CC/CPPFLAGS/CFLAGS don't show up until
late in the configure process where they are confusingly reported as a
different failure such as incorrect long double type.
As far as gcc3 knows, sh4 is the only processor version that can have an
FPU, so it indicates the FPU's presence by defining __SH4__. This is not
defined if there is no FPU, even if the processor really is an SH4.
Starting with gcc4, there is support for the sh2a processor, which has an
FPU but is not an SH4. gcc4 therefore additionally defines __SH_FPU_ANY__
when there is an FPU, but still doesn't define __SH4__ for an FPU-less sh4.
Therefore, to support all gcc versions, we must look at both preprocessor
symbols.
the previous pattern required "x32" to be used as the second field of
the gcc tuple, which is usually reserved for vendor use and not
appropriate as an ABI specifier. with this change, putting "x32" at
the end of the tuple, the way ABI specifiers are normally done, is
also permitted.
most notably, it was failing to match sh4-*, etc., but in general the
explicit matching of hyphens for some archs was problematic because it
failed to accept simply the musl-style arch name (without a gcc-style
tuple) as an input. the original motivation of matching hyphens was to
prevent incorrectly identifying a 64-bit arch as the corresponding
32-bit arch (e.g. mips* matching mips64) but this is easily fixed by
simply checking (and for now, rejecting as unsupported) the relevant
64-bit archs.
linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.
Userspace emulated floating-point (gcc -msoft-float) is not compatible
with the default mips abi (assumes an FPU or in kernel emulation of it).
Soft vs hard float abi should not be mixed, __mips_soft_float is checked
in musl's configure script and there is no runtime check. The -sf subarch
does not save/restore floating-point registers in setjmp/longjmp and only
provides dummy fenv implementation.
x32 is the internal arch name, but glibc uses x86_64-x32.
there doesn't exist a specific triple for x32 in gcc and binutils.
you're supposed to build your compiler for x86_64 and configure
it with multilib support for "mx32".
however it turns out that using a triple of x86_64-x32 makes
gcc and binutils pick up the right arch (they detect it as x86_64)
and allows us to have a unique triple for cross-compiler toolchains.
I originally added this warning option based on a misunderstanding of
how it works. it does not warn whenever the destination of the cast
has stricter alignment; it only warns in cases where misaligned
dereference could lead to a fault. thus, it's essentially a no-op for
i386, which had me wrongly believing the code was clean for this
warning level. on other archs, numerous diagnostic messages are
produced, and all of them are false-positives, so it's better just not
to use it.
this will be needed for upcoming commits to the string/mem functions
to correct their unannounced use of aliasing violations for
word-at-a-time search, fill, and copy operations.
one place where semicolon (non-portable) was still used in place of
separate -e options (copied over from an old version of this code),
and use of a literal slash in the bracket expression for the final
command, despite slash being used as the delimiter for the s command.
it turns out that __SOFTFP__ does not indicate the ABI in use but
rather that fpu instructions are not to be used at all. this is
specified in ARM's documentation so I'm unclear on how I previously
got the wrong idea. unfortunately, this resulted in the 0.9.12 release
producing a dynamic linker with the wrong name. fortunately, there do
not yet seem to be any public toolchain builds using the wrong name.
the __ARM_PCS_VFP macro does not seem to be official from ARM, and in
fact it was missing from the very earliest gcc versions (around 4.5.x)
that added -mfloat-abi=hard. it would be possible on such versions to
perform some ugly linker-based tests instead in hopes that the linker
will reject ABI-mismatching object files, if there is demand for
supporting such versions. I would probably prefer to document which
versions are broken and warn users to manually add -D__ARM_PCS_VFP if
using such a version.
there's definitely an argument to be made that the fenv macros should
be exposed even in -mfloat-abi=softfp mode. for now, I have chosen not
to expose them in this case, since the math library will not
necessarily have the capability to raise exceptions (it depends on the
CFLAGS used to compile it), and since exceptions are officially
excluded from the ARM EABI, which the plain "arm" arch aims to
follow.
the default subarch is the one whose full name is just the base arch
name, with no suffixes. normally, either the asm in the default
subarch is suitable for all subarch variants, or separate asm is
mandatory for each variant. however, in the case of asm which is
purely for optimization purposes, it's possible to have asm that only
works (or only performs well) on the default subarch, and not any othe
the other variants. thus, I have added a mechanism to give a name to
the default variant, for example "armel" for the default,
little-endian arm. further such default-subarch names can be added in
the future as needed.
check in configure to be polite (failing early if we're going to fail)
and in vfprintf.c since that is the point at which a mismatching type
would be extremely dangerous.
it's not clear that -O3 helps them, and gcc seems to have floating
point optimization bugs that introduce additional failures when -O3 is
used on some of these files.
the motivation for this patch is that the vast majority of libc is
code that does not benefit at all from optimizations, but that certain
components like string/memory operations can be major performance
bottlenecks.
at the same time, the old -falign-*=1 options are removed, since they
were only beneficial for avoiding bloat when global -O3 was used, and
in that case, they may have prevented some of the performance gains.
to be the most useful, this patch will need further tuning. in
particular, research is needed to determine which components should be
built with -O3 by default, and it may be desirable to remove the
hard-coded -O3 and instead allow more customization of the
optimization level used for selected modules.
previously, empty string was treated as "use default". this is
apparently not compatible with standard configure semantics where an
empty prefix puts everything under /. the new logic should be a lot
cleaner and not suffer from such issues.
-lpcc only works if -nostdlib is not passed, so it's useless. instead,
use -print-file-name to look up the full pathname for libpcc.a, and
check whether that succeeds before trying to link with the result.
also, silence pcc's junk printed on stdout during tests.
in old versions of pcc, the directory containing libpcc.a was not in
the library path, and other options like -print-file-name may have
been needed to locate it. however, -print-file-name itself seems to
have been added around the same time that the directory was added to
the search path, and moreover, I see no evidence that older versions
of pcc are capable of building a working musl shared library. thus, it
seems reasonable to just test whether -lpcc is accepted.
pcc wrongly passes any option beginning with -m to the linker, and
will break at link time if these options were added to CFLAGS. testing
linking lets us catch this at configure time and skip them.
for some reason this option is undocumented. not sure when it was
added, so I'm using a configure test. gcc was already setting the mark
correctly for C files, but assembler source files would need ugly
.note boilerplate in every single file to achieve this without the
option to the assembler.
blame whoever thought it would be a good idea to make the stack
executable by default rather than doing it the other way around...
based on initial work by rdp, with heavy modifications. some features
including threads are untested because qemu app-level emulation seems
to be broken and I do not have a proper system image for testing.
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...
if needed for debugging, it will be output in the .debug_frame section
instead, where it is not part of the loaded program and where the
strip command is free to strip it.
