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.
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.
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.
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.
these are needed for time64 compatibility, and are backported from the
y2038-endgame kernel branch and squashed with non-uapi changes
removed.
with just these patches applied the kernel will not build since
changes at the source level are also needed. but it is not practical
to backport source changes to an old kernel, and even if it were, it
would not make sense to include irrelevant changes that need rebasing
in a patchset intended only for the purpose of uapi header
installation.
forward-ported from the now-removed 4.4.10 patch, needed to fix#8,
spurious dependency on host elf.h header. I checked x86 and mips which
seem to be the only archs with archscripts rules, and these rules have
nothing to do with building headers, so omitting them should still be
safe.
this is binutils issue 23825, but it's caused by gcc using local-exec
model rather than initial-exec model with the intent of making
binutils generate copy relocations. this is harmful, unnecessary, and
not presently supported by musl (and probably should never be). patch
taken from https://github.com/riscv/riscv-gcc/pull/118.
new patch: 0017-c++-abi-break.diff fixes a C++ ABI break regression.
0010-static-pie-support.diff was removed as it doesn't apply anymore,
and forward-porting it requires arcane knowledge of GCC details.
the patches 0018 and 0019 have been copied from GCC 7.3.0. the static
pie patch from GCC 6.4.0, renumbered 0020, depends on the reversions
they make.
the initial-exec tls model is not valid in any code that might be
dynamically loaded. it usually happens to work on glibc because glibc
reserves some static tls space for late-loaded libraries that need it,
but if it's already been exhausted that will fail. musl does not
support this hack at all, and it's not valid for gcc target libs to be
doing it anywhere, so patch it out entirely rather than just for musl.
these are not complete/correct in that they do not account for ABI
variants (softfloat and coldfire fpu) in the dynamic linker name, but
I was unable to get gcc's configure to accept --with-float=soft on
m68k to test softfloat and begin figuring out how to do the spec
logic. at some point this needs to be figured out and completed, but
at least the default ABI is available in mcm now.
GCC 6.4.0 has one big advantage over 6.3.0: it is shipped as .tar.xz,
shaving 30 MB from its download size, and also considerably speeding
up the extraction process.
All patches are copies of the GCC 6.3.0 ones, except
0004-posix_memalign.diff which was rebased to apply cleanly.
0014-ubsan-empty-string-fix.diff was removed, since it was upstreamed.
the linker was wrongly leaving dynamic relocations for GD-model TLS
defined in the main program when linking the main program as PIE. this
was only suboptimal for dynamic pie, but for static pie it resulted in
runtime failure since there is no dynamic linker to resolve the DTPMOD
reference.
this has been reported as binutils bug #22570.
Rich Felker
rofl0r
Szabolcs Nagy
Andrew Chambers
rofl0r