https://sourceware.org/bugzilla/show_bug.cgi?id=22598
Palmer Dabbelt <palmer at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palmer at gcc dot gnu.org
--- Comment #3 from Palmer Dabbelt <palmer at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #2)
> Note that the testcase is trying to use absolute addresses with a
> pc-relative branch. The assembler can't know the address the linker will
> assign to the code, so this requires a relocation. I don't know if we have
> one offhand. We do have one for jal though.
Ah, there's a good question: is "beq x0, x0, -4" a branch to address "-4" or a
branch to "pc-4"? I think the people who are asking for this usually want the
assembler to just get out of the way and put that exact value in their branch
opcode, which is what I assumed (and could be implemented via R_RISCV_BRANCH).
Now that you mention it I'm not sure what the right interpretation of "br REG,
REG, LITERAL" is.
Are there any conventions for this? As the RISC-V toolchain currently stands
you can't really reason directly about text addresses (just symbols), so I
don't think we have any strong precedent. Currently, we treat
* "auipc REG, LITERAL" as "set REG to pc+shift(LITERAL)", as opposed to "set
reg to LITERAL".
* "lui REG, LITERAL" as "set REG to pc+shift(LITERAL)", as opposed to "set reg
to LITERAL".
* "ld REG1, LITERAL(REG2)" as "set REG1 to memory[REG2+LITERAL]", though I
guess there's no other way to interpret that.
Another option would be to implement the long RISC-V instruction format and
treat that as "give me exactly these instruction bits". I guess that's kind of
the same as the strict option.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
