[PATCH] LD/PE: Remove remains of MIPS target support

[Jan Beulich]

On 25.08.2025 01:56, Maciej W. Rozycki wrote:
> +Cc DJ, for original Win32 x86 support.
> 
> On Fri, 22 Aug 2025, Jan Beulich wrote:
> 
>>>>>  I agree.  Would the cc'd maintainers of the other PE targets please 
>>>>> confirm or deny that these high-part/low-part relocations are used by 
>>>>> their respective platforms (ISTM they are not, so I chose to remove that 
>>>>> code as dead with the removal of MIPS support, but I'll appreciate a 
>>>>> second opinion)?
>>>>
>>>> Sadly by experience I wouldn't expect any replies there. But maybe I can
>>>> be positively surprised ...
>>>>
>>>> (My personal take is that at least the "case BITS_AND_SHIFT (16, 0):"
>>>> part may better be left in.)
>>>
>>>  If no one chimes in, I'd be tempted to discard this anyway, especially as 
>>> we're early in the cycle now.  We can add it back if someone screams later 
>>> on.
>>
>> Actually no, this needs to stay - even x86 can come through this path, for
>> what originally would have been BFD_RELOC_16 (easily encodable in assembly
>> sources, and hence also in inline assembly).
> 
>  I don't buy it.  While a standalone BFD_RELOC_16 relocation would make 
> sense for 16-bit x86 target code (does this DLL handling code even support 
> that?; it says "Win32 etc" at the top), firstly this linker code came in 
> along with MIPS support while x86 had been already supported and secondly 
> the name of the relocation's data type clearly indicates this is for the 
> low-part reloc in a high/low pair.  I don't think any high/low relocation 
> pairs are ever used with x86 code; immediate addends are either 8-bit or 
> full 32-bit in the 32-bit[*] x86 instruction set (and obviously 8-bit ones 
> are not suitable to refer to symbols, but can instead be used to access 
> structure members, etc.).
> 
>  Can you come up with any valid compiled x86 code that triggers this path?  
> If so, then the assembly produced, possibly reduced, ought to become an LD 
> testsuite case to exercise this path.  Otherwise I maintain this piece can 
> be dropped as dead code.

What I know is that I saw the resulting relocation type (bogusly) in use
in binaries. Surely there are bugs elsewhere; possibly [1] is enough for
that to not happen anymore. Yet still is feels risky to remove code which
cannot be proven that it is entirely unused.

Jan

[1] https://sourceware.org/pipermail/binutils/2025-August/143530.html

> [*] As in: "suitable for code using 32-bit addressing"; I won't get into 
>     the intricacies of the 0x67 address size prefix here.
> 
>   Maciej