As we prepare binutils for upstreaming we want to start closely tracking
upstream changes. There's a riscv-binutils-gdb repository that contains
the binutils port, and I want to centralize all the development there.
This commit uses that repository instead of the patches that used to
live here, so we're less likely to lose patches.
In addition to some small changes, here's the bigger ones:
* gen_rtx_SET no longer takes a VOIDmode, apparently that was the only
valid argument in that position so it's been dropped.
* GEN_CALL is now gen_call.
* The #defines in riscv.h need to be defined to 1, not just defined,
since they're now used in "if ()" statements.
* glibc is passed "--disable-werror", since the new GCC throws a bunch
of pointless errors like "misleading indentation". This is all in
upstream glibc code.
This installs the headers to the same place, but for some reason
something on a2 isn't working correctly and is trying to remove the
headers from /usr first.
It's no longer the case that building the toolchain with
"--disable-float" turns off floating-point by default. This passes the
correct arguments to all the various sub-configures in order to ask for
floating-point support to be either enabled or disabled.
There was one change required here: support for "MEMMODEL_SYNC_*". This
very long GCC post <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697>
talks about the formalization of the C++ memory model. It looks like
this is it to allow for some ARM stupidity where they can speculatively
issue some memory operations.
As far as I can tell, the right thing to do here is to just treat the
SYNC versions the same as the non-SYNC versions -- this is the same
thing ia64 and rs600 do. I can't find "MEMMODEL_SYNC" anywhere else
interesting, so there might be some flag to set to avoid doing this, but
I couldn't find it.
This just requires a single extra argument to a function call, which I copied
from aarch64. I've only tested that newlib builds, but I don't see how this
could cause any problems... :)
I was hoping this would help with my attempts to integrate the GDB and binutils
ports into one repo for upstreaming, but it looks like 2.25.1 is still a bit
too old for this.
"cp -a" preserves everything about the copied files, the most
important of which for us is the modification times. It appears all
the GNU stuff has sufficiently broken toolchains such that randomizing
the order of the modification times of the distributed sources is
sufficient to break the build. I'm hoping this fixes an intermittent
failure in my builds.
I commited this too quickly last time and it's been breaking a whole
bunch of stuff. Until I managed to get multilib working in a sane
way, I'm just going to go ahead and turn it off by default. You can
still pass "--with-arch", but doing so while also passing things like
"--enable-multilib" or "--disable-atomics" might have unexpected
results.
Doing so prevents -m32/-m64 from having any effect. This patch is just
a workaround; we should fix the runtime handling of --with-arch so that
specifying -m32/-m64 on the command line takes priority.
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).
buildbot.dabbelt.com recently failed because it was unable to fetch
the downloaded files fast enough because mirrors.kernel.org was being
slow. This patch allows me to cache the downloaded files somewhere to
avoid these sorts of network problems.
This should also be generally useful for other people who build the
toolchain regularly.
I thought this was a problem with the build, but it turns out that was
actually related to my bad (and now reverted) patch from earlier this
week.
Regardless, this is the canonical way to build a cross compiler so now
that it's done I don't see a reason not to use it.
We used to allow GCC to fail the stage1 build because it's impossible
to build the full GCC without glibc. This builds just the parts we
need ("all-gcc" and "all-target-libgcc") and then install them.
This should make build failures a bit easier to debug, as now nothing
should fail.
Wherever possible, rely on facilities native to GNU make rather than
invoke external utilities superfluously. Change the shell to /bin/sh
instead of bash since the latter's heftier feature set is unnecessary.
The -r option to cp(1) is marked obsolescent by POSIX; use -R instead.
Select between curl(1), wget(1), and ftp(1) through autoconf.
Wherever possible, automatically follow HTTP location redirects and
enable passive FTP mode.
Explicitly instruct tar(1) to read from stdin since this is far from
universal behavior if unspecified: The default file is /dev/sa0 in
FreeBSD, /dev/rst0 in NetBSD and OpenBSD, etc.
Tests for program presence, such as those formerly embedded in the
top-level Makefile for gawk and gsed, are better suited for autoconf.
Note that it is not sufficient to merely export AWK and SED environment
variables, as packages may still directly invoke awk(1) and sed(1) with
non-standard features independent of the autotools framework.
Wrapper scripts therefore remain necessary, although these are now
generated by the configure script to avoid hard-coded paths.
Do not assume the existence of /bin/bash on all systems.
I keep forgetting that the default option is to build newlib. This
flag changes the default target to Linux, so I don't keep forgetting
to type "make linux".
Some shared binutils source code throws some harmless looking errors
with newer GCC versions. This patch stops failing the binutils build
whenever these errors show up.
Both Gentoo and LFS set this flag, so I think it's sane.
Andrew Waterman
Palmer Dabbelt
Palmer Dabbelt
Colin Schmidt
SeungRyeol Lee
Darius Rad
Scott Beamer
Andrew Waterman
Albert Ou
Andrew Waterman