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.
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.
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.
So it turns out that the uapi stuff also broke libsanitizer in some
trivial ways -- essentially we need to replace the old version of the
*at syscalls with the new *at version and some flags. Upstream has
already fixed this, so all I really did is backport part of an
upstream patch that I don't care to track down the exact origin of:
commit 7d752f28b590bbad13c877c2aa7f5f8de2cdff10
Author: kcc <kcc@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Thu May 22 07:09:21 2014 +0000
libsanitizer merge from upstream r209283
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210743 138bc75d-0d04-0410-961f-82ee72b054a4
Note that this will:
* Break on anything that doesn't support uapi.
* Conflict with the patch that I assume will land in GCC-5.0.
Neither of which I think are important -- just don't build
riscv-gnu-toolchain for anything that's not RISC-V, and drop the patch
when you rebase to 5.0.
This is necessary to get Gentoo to build, as it builds libsanitizer.
We over-emit NOPs in the assembler, then delete them in the linker to achieve
the required alignment. This allows alignment to work in spite of other
linker relaxations.
v0-1 are removed; arguments are now returned in a0-1. Registers are
renumbered so that s0-1 and a0-5 map to x8-15 to simplify the RVC ISA.
(These are the most popular 8 registers besides x0 and sp.)
This allows the local-exec model to be used for any non-PIC TLS reference,
even if it cannot be proven at compile time that the access binds locally.
It essentially obviates the need for IE -> LE relaxations.
Previously, we had multiple low-part PC-relative relocs, e.g.
R_RISCV_GOT_LO12 and R_RISCV_TLS_GD_LO12. But since these are indirect
relocs and enough info is encoded in the high part, they are redundant.
Now, we only have two: R_RISCV_PCREL_LO12_I and R_RISCV_PCREL_LO12_S.
For example, the following PIC code adds TLS variables x and y:
.L1: auipc a0, %tls_ie_pcrel_hi(x)
.L2: auipc a1, %tls_ie_pcrel_hi(y)
ld a0, %pcrel_lo(.L1)(a0)
ld a1, %pcrel_lo(.L2)(a1)
ld a0, 0(a0)
ld a1, 0(a1)
add a0, a0, a1
Andrew Waterman
Mike Frysinger
Palmer Dabbelt
Albert Ou
Darius Rad
Andrew Waterman