bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/22598] [RISCV] No way to disable two-instruction sequences for


From: palmer at gcc dot gnu.org
Subject: [Bug gas/22598] [RISCV] No way to disable two-instruction sequences for branch or relocation for jal instructions
Date: Tue, 09 Jan 2018 05:36:38 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=22598

--- Comment #5 from Palmer Dabbelt <palmer at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #4)
> I would expect this to work
>       .option norelax
>       beq s1, s0, .+102
>       bne a4, a5, .-4096
>       jal a2, 1048574
> I get
> 00000000 <.L0 >:
>    0: 06848363                beq     s1,s0,66 <.L0 +0x62>
>                       0: R_RISCV_BRANCH       .L0 +0x66
> 
> 00000004 <.L0 >:
>    4: 80f71063                bne     a4,a5,fffff004 <.L0 +0xfffff000>
>                       4: R_RISCV_BRANCH       .L0 -0x1000
>    8: 0000066f                jal     a2,8 <.L0 +0x4>
>                       8: R_RISCV_JAL  *ABS*+0xffffe
> which looks mostly OK, but the <address> printed doesn't seem to match the
> disassembly, or the relocs.  Something (maybe me) appears to be a little
> confused here.

Ah, that smells like the right answer here: just make the PC-relativeness
explicit for branches.  That way there's no ambiguity as to how the branch
target is encoded.

I think we can actually resolve this as FIXED.  Jim has uncovered another bug
where we frequently produce worthless address hints, particularly for object
files (ie, not having been linked yet).  I think this particular case is
esoteric enough that it's not worth implementing another heuristic for, but it
might be worth considering a "don't provide address hints based on
FAKE_LABEL_NAME" as a feature in our disassembler.  They're still useful when
poking around inside relocations though, so we'll seem something slightly
smarter than that.

Alex: are you OK with resolving this as FIXED and requiring you to use
".+OFFSET"?  The theory here is that you wanted PC-relative offsets in your
branches, not absolute addresses.  If you want absolute addresses that would
both require a new relocation.  Since it would usually produce a linker error,
as you're probably not within a 12-bit PC-relative offset of these small
constants, it doesn't seem like it's worth adding the relocation for.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]