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.
We sometimes use t0 as a link register, e.g. for the compressed prologues
and epilogues, and so we want microarchitectures to push the RAS when
rd=t0 and pop the RAS when rs1=t0. Thus, we want to avoid using t0 for
indirect calls to avoid errant RAS operations.
If a call crosses an alignment directive, the PC-relative offset could
actually increase post-relaxation. Account for this by assuming the
offset could increase by up to a page size when the caller and callee
lie in different output sections.
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.
This simply stops GCC's parse whenever it sees an 'X' in an ISA
string. This is the best I can do until some clarafications are made
to the RISC-V user spec that allows ISA extensions to be parsed.
Some glibc floating point routines use inline assembly. This changes
them to use regular C code to do this when compiled without hardware
floatint-point support. The change just uses regular C to perform
these operations when compiled on ABIs without hardware floating
point.
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.
Palmer Dabbelt
Andrew Waterman
Andrew Waterman
Palmer Dabbelt
Mike Frysinger
Sven Stucki