RISC-V: PR31179, The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects

* Problematic fix commit,
2029e13917d53d2289d3ebb390c4f40bd2112d21
RISC-V: Clarify the behaviors of SET/ADD/SUB relocations

* Bugzilla,
https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5

The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it
non-zero by accident in assembler before.  This causes troubles by applying
the above commit, since the calculation is changed to support .reloc *SUB*
relocations with non-zero addend.

We encourage people to rebuild their stuff to get the non-zero addend of
SUB_ULEB128, but that might need some times, so report warnings to inform
people need to rebuild their stuff if --check-uleb128 is enabled.

Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use,
it may acceptable that stop supproting them until people rebuld their stuff,
maybe half-year or a year later.  Or maybe we should teach people that don't
write the .reloc R_RISCV_SUB* with non-zero constant, and then report
warnings/errors in assembler.

bfd/
	* elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of
	R_RISCV_SUB_ULEB128.
	(riscv_elf_relocate_section): Report warnings to inform people need
	to rebuild their stuff if --check-uleb128 is enabled.  So that can
	get the right non-zero addend of R_RISCV_SUB_ULEB128.
	* elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128.
ld/
	* NEWS: Updated.
	* emultempl/riscvelf.em: Added linker risc-v target options,
	--[no-]check-uleb128, to enable/disable checking if the addend of
	uleb128 is non-zero or not.  So that people will know they need to
	rebuild the objects with binutils 2.42 and up, to get the right zero
	addend of SUB_ULEB128 relocation, or they may get troubles if using
	.reloc.
	* ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
	* ld/testsuite/ld-riscv-elf/pr31179*: New test cases.

0 files changed, 0 insertions, 0 deletions