[PATCH v2 5/6] bfd/ELF: fold BFD_RELOC_<arch>_PCREL*

[Jan Beulich]

On 28.03.2026 04:41, mengqinggang wrote:
> 
> 在 2026/3/27 17:58, Jan Beulich 写道:
>> There's no need to have a separate reloc per arch; just like for other
>> more or less generic ones a single one will (mostly) do, as long as the
>> resulting reloc's properties fit such a generic use (in the assembler it
>> could, after all, also result from ordinary expressions or uses with the
>> .reloc directive). Arm64, C-Sky, and KVX - sadly - are once again
>> exceptions.
>>
>> For cris it's a PLT reloc which is being replaced.
>>
>> For msp430 also drop BFD_RELOC_MSP430_16_BYTE, which has already been
>> merely an alias of BFD_RELOC_16 (resolving to R_MSP430_16_BYTE).
>> ---
>> It's not clear to me why LoongArch's "fast" lookup stopped at
>> BFD_RELOC_LARCH_RELAX (which is also unlike the range special cased in
>> gas); subsequent relocations also are contiguous. IOW instead of dropping
>> BFD_RELOC_LARCH_{32,64}_PCREL (and moving the "terminator" slightly back),
>> the target may want (need) excluding here as well.

Hmm, I'm a little confused. On v1 you said, in reply to this remark, that
the change is good for LoongArch. Now suddenly ...

>> --- a/bfd/elfxx-loongarch.c
>> +++ b/bfd/elfxx-loongarch.c
>> @@ -1389,7 +1389,7 @@ static loongarch_reloc_howto_type loonga
>>   	 0,					/* src_mask */
>>   	 0xffffffff,				/* dst_mask */
>>   	 true,					/* pcrel_offset */
>> -	 BFD_RELOC_LARCH_32_PCREL,		/* bfd_reloc_code_real_type */
>> +	 BFD_RELOC_32_PCREL,			/* bfd_reloc_code_real_type */
>>   	 reloc_sign_bits,			/* adjust_reloc_bits */
>>   	 NULL),					/* larch_reloc_type_name */
>>   
>> @@ -1581,7 +1581,7 @@ static loongarch_reloc_howto_type loonga
>>   	 0,					/* src_mask */
>>   	 0xffffffffffffffff,			/* dst_mask */
>>   	 true,					/* pcrel_offset */
>> -	 BFD_RELOC_LARCH_64_PCREL,		/* bfd_reloc_code_real_type */
>> +	 BFD_RELOC_64_PCREL,			/* bfd_reloc_code_real_type */
>>   	 NULL,					/* adjust_reloc_bits */
>>   	 NULL),					/* larch_reloc_type_name */
>>   
>> @@ -2144,10 +2144,10 @@ loongarch_reloc_type_lookup (bfd *abfd A
>>     BFD_ASSERT (ARRAY_SIZE (loongarch_howto_table) == R_LARCH_count);
>>   
>>     /* Fast search for new reloc types.  */
>> -  if (BFD_RELOC_LARCH_B16 <= code && code < BFD_RELOC_LARCH_RELAX)
>> +  if (BFD_RELOC_LARCH_B16 <= code && code <= BFD_RELOC_LARCH_TLS_GD_HI20)
>>       {
>> -      BFD_ASSERT (BFD_RELOC_LARCH_RELAX - BFD_RELOC_LARCH_B16
>> -		  == R_LARCH_RELAX - R_LARCH_B16);
>> +      BFD_ASSERT (BFD_RELOC_LARCH_TLS_GD_HI20 - BFD_RELOC_LARCH_B16
>> +		  == R_LARCH_TLS_GD_HI20 - R_LARCH_B16);
> 
> This assert need to be deleted. Without BFD_RELOC_LARCH_{64,32}_PCRE,
> the assert may fail for some relocations.

... you want this assertion deleted rather than changed as presented. As per
the remark above, the change is specifically to prevent it triggering
unexpectedly: BFD_RELOC_LARCH_64_PCREL has been outside of the checked range
already before this change. The adjustment is to move
BFD_RELOC_LARCH_32_PCREL out of that range, too. If you still see a
possibility of the assertion triggering when it shouldn't, I guess this
would be an issue without this change as well? Otherwise, can you please be
more specific about what you see (and what I'm apparently missing)?

Jan