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

[mengqinggang]

在 2026/3/30 14:26, 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

Sorry for the confusion.
You are right, please carry on!
I thought deleting this assert would enable fast look for all the 
relocations.

Thanks,
Meng