Even in shared objects, la.got -> la.pcrel relaxation can still be
performed for symbols with hidden visibility. For example, if a.c is:
extern int x;
int f() { return x++; }
and b.c is:
int x = 114514;
If compiling and linking with:
gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c
Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
should be like:
pcaddi $t0, x
ldptr.w $a0, $t0, 0
addi.w $t1, $a0, 1
stptr.w $t1, $t0, 0
ret
Remove bfd_link_executable from the condition of la.got -> la.pcrel
relaxation so this will really happen. The SYMBOL_REFERENCES_LOCAL
check is enough not to wrongly relax preemptable symbols (for e.g.
when -fvisibility=hidden is not used).
Note that on x86_64 this is also relaxed and the produced code is like:
lea x(%rip), %rdx
mov (%rdx), %rax
lea 1(%rax), %ecx
mov %ecx, (%rdx)
ret
Tested by running ld test suite, bootstrapping and regtesting GCC with
the patched ld, and building and testing Glibc with the patched ld. No
regression is observed.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
these two instructions must adjacent.
The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.
2023-12-15 John David Anglin <danglin@gcc.gnu.org>
PR ld/31148
bfd/ChangeLog:
* elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output
relative reloc only when eh->root.type is bfd_link_hash_defined
or bfd_link_hash_defweak.
Hi,
This patch adds support for the Cortex-X3 CPU to binutils.
Gas regression testing for aarch64-none-linux-gnu target and found no regressions.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
match/mask encoding in `micromips_opcodes'. It is correctly specified
to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
code like _bfd_mips_elf32_gprel16_reloc.
Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
when little-endian. Big-endian behaviour is unchanged after this
patch and little-endian correctly applies the reloc to byte 0x11.
The patch also corrects REL addend extraction from section contents,
and overflow checking. gold had all of the bfd problems with this
reloc and additionally did not apply the rightshift by two.
bfd/
* elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
R_MICROMIPS_GPREL7_S2.
(mips_elf_calculate_relocation): Correct sign extension and
overflow calculation for R_MICROMIPS_GPREL7_S2.
(_bfd_mips_elf_relocate_section): Update small-data overflow
message.
gold/
* mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
Return false for R_MICROMIPS_GPREL7_S2.
(Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
(Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
handling.
(Mips_relocate_functions::relgprel7): New function.
(Target_mips::Relocate::relocate): Adjust to suit.
ld/
* testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
* testsuite/ld-mips-elf/reloc-5.d: Likewise.
This was split over multiple lines and ended up missing a space.
Reported-by: David Abdurachmanov <davidlt@rivosinc.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
PR 31106
* elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation.
This is aimed at fixing holes in two alpha-ecoff relocation functions
that access section contents without first bounds checking offsets.
I've also rewritten ALPHA_R_OP_STORE handling to support writing to
the bytes near the end of the section.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't
bother checking ALPHA_R_LITERAL insn. Range check before reading
contents for ALPHA_R_GPDISP, and simplify handling. Rewrite
ALPHA_R_OP_STORE handling. Correct error callback args.
(alpha_relocate_section): Similarly. Don't abort, report errors.
In commit 7ac6d0c38c I made more use of free_contents in
_bfd_elf_slurp_version_tables, a variable added to tag the case where
raw verneed and verdefs have been read locally by the function, and
thus should be freed before returning. In retrospect it may have been
better to do without the extra variable entirely. It's easy to infer
when "contents" should be freed, costing a little extra on an error
path but costing less elsewhere.
* elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents.
riscv_is_mapping_symbol currently accepts any symbol that starts with $x
or $d. This patch makes the check more strict, requiring exactly $x, $d,
or $xrv. It also makes use of this stricter mapping in
riscv_is_valid_mapping_symbol.
ChangeLog:
* bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only
strings that are exactly $x, $d, or $xrv.
* opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use
riscv_elf_is_mapping_symbols.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
SiFive has define as set of flexible instruction for extending vector
coprocessor, it able to encoding opcode like .insn but with predefined
format.
List of instructions:
sf.vc.x
sf.vc.i
sf.vc.vv
sf.vc.xv
sf.vc.iv
sf.vc.fv
sf.vc.vvv
sf.vc.xvv
sf.vc.ivv
sf.vc.fvv
sf.vc.vvw
sf.vc.xvw
sf.vc.ivw
sf.vc.fvw
sf.vc.v.x
sf.vc.v.i
sf.vc.v.vv
sf.vc.v.xv
sf.vc.v.iv
sf.vc.v.fv
sf.vc.v.vvv
sf.vc.v.xvv
sf.vc.v.ivv
sf.vc.v.fvv
sf.vc.v.vvw
sf.vc.v.xvw
sf.vc.v.ivw
sf.vc.v.fvw
Spec of Xsfvcp
https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software
Co-authored-by: Hau Hsu <hau.hsu@sifive.com>
Co-authored-by: Kito Cheng <kito.cheng@sifive.com>
Back then when the support for the RISC-V vector crypto extensions
was merged, the specification was frozen, but not ratified.
A frozen specification is allowed to change within tight bounds
before ratification and this has happend with the vector crypto
extensions.
The following changes were applied:
* A new extension Zvkb was defined, which is a strict subset of Zvbb.
* Zvkn and Zvks include now Zvkb instead of Zvbb.
This patch implements these changes between the frozen and the
ratified specification.
Note, that this technically an incompatible change of Zvkn and Zvks,
but I am not aware of any project that depends on the currently
implemented behaviour of Zvkn and Zvks. So this patch should be fine.
Reported-By: Jerry Shih <jerry.shih@sifive.com>
Reported-By: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This behavior is used by downstream toolchain since 2014,
and has been in GCC since the same year.
We don't support mips64*-img* due to GCC doesn't support it,
and we believe that the multilib should be used for this case.
Because the 'Zfa' extension has a version number of 1.0
(not 0.1). This commit updates the number.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
number of the 'Zfa' extension since it's ratified.
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds the sub-extension "XTheadZvamo" for the
"XTheadVector" extension, and it provides AMO instructions
for T-Head VECTOR vendor extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add support
for "XTheadZvamo" extension.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* doc/c-riscv.texi:
* testsuite/gas/riscv/x-thead-vector-zvamo.d: New test.
* testsuite/gas/riscv/x-thead-vector-zvamo.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_TH_VAMOADDWV): New.
* opcode/riscv.h (enum riscv_insn_class): Add insn class.
opcodes/ChangeLog:
* riscv-opc.c: Likewise.
T-Head has a range of vendor-specific instructions ([2]).
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the "XTheadVector" extension, a collection of
T-Head-specific vector instructions. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the RISC-V
toolchain conventions ([1]).
Here are some things that need to be explained:
The "XTheadVector" extension is not a custom-extension, but
a non-standard non-conforming extension. The encoding space
of the "TheadVector" instructions overlaps with those of
the 'V' extension. This encoding space conflict is not on
purpose, but the result of issues in the past that have
been resolved since. Therefore, the "XTheadVector" extension
and the 'V' extension are in conflict.
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
[2] https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): The
"XTheadVector" extension and the 'V' extension are in conflict.
(riscv_multi_subset_supports): Likewise..
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* doc/c-riscv.texi:
* testsuite/gas/riscv/x-thead-vector-fail.d: New test.
* testsuite/gas/riscv/x-thead-vector-fail.l: New test.
* testsuite/gas/riscv/x-thead-vector.s: New test.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class):
