https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #11 from Jim Wilson <wilson at gcc dot gnu.org> ---
You must be careful when interpreting an unrelocated object file. The
relocation
0: R_MIPS_PC16 *ABS*
makes it clear that you have a zero-based absolute address in the branch.
The disassembler is stupid. It doesn't look at relocs, even when you use -r.
When printing an address, it chooses the closest label to the target address.
Also, MIPS (and RISC-V) have inplace pc-relative relocs, which means the
absolute target address gets written into the branch/jump instruction by the
assembler if possible to be fixed by the linker when relocs are resolved.
Since we have a 16-bit offset here, and the target address is 128 it fits just
fine. So it looks like you have a branch to label+128, but it isn't because of
the reloc.
If you run this through the linker, label gets relocated into the default text
start section which is above 0x10000, and then you will get a relocation error
because the absolute target address 128 is not in range of the final location
of the branch instruction. This is why I was careful to run it through the
linker in my example, to prove that it is an absolute address.
So the MIPS target is working the same as RISC-V. Immediate arguments to a
branch are absolute target addresses. The only issue for RISC-V is the
code-deleting linker relaxations which complicate everything, and force us to
emit relaxable branch sequences in the assembler.
--
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
