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

[Maciej W. Rozycki]

+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.

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

  Maciej