GCC's softfloat is built by default without support for dynamic
rounding modes. This makes softfloat newlib's floating point always
round-to-zero, and returns a failure code when trying to set it.
This patch is needed to make newlib compile on anything without F, as
it used to try use an undefined instruction to do this.
gas currently defaults to xlen=64 all the time even when it's configured
for a riscv32-elf target. Fix this by leveraging the existing default
arch logic like x86/s390 targets do.
The meaning of "arch" is a bit confusing in this case as we're using it
only for the xlen and not for the various extensions. But since this is
really the only thing we pull from the tuple, and it's the naming that
the common gas code uses, oh well.
There are times when the disassembler doesn't have a fully formed elf
(like when using gdb). Change the extension logic to not require that
so we don't crash with segfaults.
I guess it wouldn't be a proper GCC update if it didn't break the
libsanitizer port :). I feel like they've picked the most convoluted
set of #ifdefs possible in order to achieve this, but I just stuck
__riscv__ in some slightly different places than last time so at least
it wasn't any work to fix.
This doesn't break riscv64-unknown-linux-gnu on a5, and fixes Gentoo.
It turns out LD runs relax_section multiple times even if *again is false.
We need to use our own mechanism to prevent relaxing a section again
after R_RISCV_ALIGN has been handled, or else we can break alignment.
I have no idea why, but the installed "sed" wrapper never terminates
on RHEL. If I don't use the wrappen the the tools build fine, so this
just uses the already set autoconf variables to attempt to determine
if the system sed/awk are gsed/gawk and if they are then this avoids
using the wrappers.
There's a few oddities here:
* I have no idea why the sed wrapper fails, as it seems super safe.
* I haven't run into any awk problems, but I figured I'd treat it the
same as it isn't any harder.
* We shouldn't have to support 10 year old distributions.
Hopefully this doesn't break anyone's builds...
Some systems don't have things like GMP, MPFR, and friends installed.
Rather than requiring them to be installed as root, this uses a bit of
GCC's built-in functionality to download these libraries and build
them along with GCC.
This allows the tools to build on Red Hat, but only if you install
newer host tools (I have GCC, make, and texinfo).
I've been getting sporadic binutils build failures for a while that
all look something like
.../src/binutils/bfd/cpu-riscv.c:51:5: error: ‘bfd_arch_riscv’ undeclared here (not in a function)
bfd_arch_riscv, \
^
...
Makefile:1605: recipe for target 'cpu-riscv.lo' failed
make[6]: *** [cpu-riscv.lo] Error 1
make[6]: *** Waiting for unfinished jobs....
I belive the problem here is that "bfd.h" is in the middle of being
generated while this build step is being run. This can happen because
of a missing dependency, which you can verify by running
$ cd build-binutils-linux/bfd
$ rm stmp-bfd-h bfd.h cpu-riscv.lo
$ make cpu-riscv.lo
which will fail because "bfd.h" doesn't get regenerated. This patch
fixes that dependency problem by adding some RISC-V files to
ALL_MACHINES{,_CFILES}, which appears to be necessary to get the
dependency to work correctly (though I have no idea where it's coming
from).
It remains to be seen if this fixes the parellal build problem, but
this is certianly a bug.
Andrew Waterman
Palmer Dabbelt
Andrew Waterman
Mike Frysinger
Sven Stucki
Palmer Dabbelt