this adds support for riscv and fixes a bug in swab.h, allowing
to build newer kernels - the objtool component is built using
host kernel headers, not the ones available in-tree.
these were added when arm fdpic support was upstreamed in gcc. one patch
was just entirely wrong (broke arm init/fini arrays, gcc pr#114158) and
the other put arm-specific unwind logic in place for all fdpic targets
and broke building of the unwinder code.
this directory uses relative pathnames to access libgcc unwind
headers, but with cowpatch, those are relative to the libstdc++-v3
directory in the unpatched tree unless libstdc++-v3 has been
cow-split.
this calls for a general solution at some point, but for now, just add
an explicit dummy patch to trigger cow splitting.
http://isl.gforge.inria.fr was deprecated for some time and is now
down. This patch updates the download location to the new sourceforge
upstream location of the ISL project.
I overlooked that GCC was not doing this by default for musl, since
binutils ld automatically converts the .ctors/.dtors GCC emits to
init/fini arrays at link time. unfortunately lld does not do the same,
so without --enable-initfini-array, GCC produces object files that lld
will mislink unless it was configured with support for legacy GCC
ctors.
this is a critical wrong-codegen bug in gcc 9 and 10 that can have
security impact, and oddly the fix still does not seem to have been
backported, so just disable builtin memcmp expansion entirely until
there's a known-good fix.
the 60840 fpu and later, and coldfire fpus, have precision-specific
sqrt instructions that get used and do the right thing. only when
targeting baseline (or near-baseline) ISA does the ld80-only
instruction get used, and that's all that needs to be suppressed.
gcc pr 95921. the m68k sqrt rtl handles excess precision wrong. I
couldn't figure out how to make gcc generate the insn only for long
double, but since long double usage is rare anyway, just remove it.
this can be replaced with a proper fix later if there's ever one
upstream.
gmp has its own wrapper version of this file and calls the real one
configfsf.sub. within the gcc build, replacing the wrong one is
harmless, but it breaks independent use of the patched gmp tree and
it's logically wrong.
patch by Laurent Bercot.
reportedly the vdso version of clock_gettime64 produces erratic
results on arm with linux 5.6, and earlier versions did not have the
vdso function at all. it's not clear what the eventual upstream
solution will be, but something needs to be done so as not to be
producing binaries that seem to work now but will break fantastically
when moving to newer kernels.
PWD is set by the shell, not make, and might not match.
For example, this broke the build through Homebrew, because
PWD stays at the directory where brew is ran.
previously this was missed because there's target-specific spec magic
for a few targets to do it, but many including arm don't have it.
without this, use of -static-pie produces broken binaries which lack
an interpreter but link to shared libraries on the targets affected.
use of -static -pie (preferred form) is not affected. gcc versions
prior to 8.x did not have -static-pie (because there was no upstream
static pie support) so this patch is only needed for 8+, and only to
prevent breakage if someone uses the -static-pie option instead of
-static with -pie.
gmp does not build correctly with compilers that default to emitting
PIE/PIC, due to custom-preprocessed asm source files which have wrong
logic for determining if PIC-compatibility is needed. ideally this
would be patched in gmp, but I don't know how to do that, so for the
time being, just disable the asm.
now that config.guess knows how to detect musl, it's possible when
building on a musl-based system that $build will spuriously match
$target, preventing the desired behavior of building as a cross
compiler or as a cross-compiled native compiler.
run config.guess and config.sub from the litecross makefile to check
if $build is going to match $target, and if so, append junk to the
libc/abi part of the $build tuple so that it no longer matches.
this should be a nop since we're either building a cross compiler or
cross compiling, but due to recent gcc's config.guess detecting musl,
it's possible to spuriously get $build=$host=$target, and then the
dreaded bootstrap procedure runs and breaks the output.
rofl0r
Rich Felker
Viktor Szakats
Kevin Bortis
Szabolcs Nagy
fanquake
IceCodeNew
Peter Jin
Filippo Valsorda