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

[Maciej W. Rozycki]

On Wed, 8 Oct 2025, Jan Beulich wrote:

> > $ arm-pe-ld -o long.exe long.o
> > short.o:(.data+0x2): relocation truncated to fit: ARM_16 against symbol `foo' defined in .data section in short.o
> > $ echo $?
> > 1
> > $ 
> > 
> > So we've got a link failure, which shows that the `BITS_AND_SHIFT (16, 0)' 
> > case cannot trigger for ARM.
> 
> The link failure is a result of what specific value the target symbol takes.
> For a suitably selected symbol no such error would result. Hence ...

 D'oh, you're of course right!  I do know what "relocation truncated to 
fit" error means (however contrived the wording seems) and just didn't 
realise the implication on this occasion.  Sigh!

> >  I have verified analogous link failures result for i386/PE and x86_64/PE; 
> > I'm leaving it up to you as an x86 expert to experiment with if you like.
> > 
> >  In any case this proves my point with the original submission.
> 
> ... I disagree with this conclusion.

 And right you are:

$ arm-pe-ld -image-base=0x1000 -o short.exe short.o
$ arm-pe-objdump -p short.o

short.exe:     file format pei-arm-little

Characteristics 0x306
	executable
	line numbers stripped
	32 bit words
	debugging information removed

Time/Date		Wed Oct  8 17:55:59 2025
Magic			010b	(PE32)
MajorLinkerVersion	2
MinorLinkerVersion	45
SizeOfCode		00000000
SizeOfInitializedData	00000600
SizeOfUninitializedData	00000000
AddressOfEntryPoint	00001000
BaseOfCode		00000000
BaseOfData		00001000
ImageBase		00001000
SectionAlignment	00001000
FileAlignment		00000200
MajorOSystemVersion	4
MinorOSystemVersion	0
MajorImageVersion	1
MinorImageVersion	0
MajorSubsystemVersion	3
MinorSubsystemVersion	0
Win32Version		00000000
SizeOfImage		00005000
SizeOfHeaders		00000400
CheckSum		0000f422
Subsystem		00000002	(Windows GUI)
DllCharacteristics	00000000
SizeOfStackReserve	00200000
SizeOfStackCommit	00001000
SizeOfHeapReserve	00100000
SizeOfHeapCommit	00001000
LoaderFlags		00000000
NumberOfRvaAndSizes	00000010

The Data Directory
Entry 0 00000000 00000000 Export Directory [.edata (or where ever we found it)]
Entry 1 00003000 00000014 Import Directory [parts of .idata]
Entry 2 00000000 00000000 Resource Directory [.rsrc]
Entry 3 00000000 00000000 Exception Directory [.pdata]
Entry 4 00000000 00000000 Security Directory
Entry 5 00004000 0000000c Base Relocation Directory [.reloc]
Entry 6 00000000 00000000 Debug Directory
Entry 7 00000000 00000000 Description Directory
Entry 8 00000000 00000000 Special Directory
Entry 9 00000000 00000000 Thread Storage Directory [.tls]
Entry a 00000000 00000000 Load Configuration Directory
Entry b 00000000 00000000 Bound Import Directory
Entry c 00000000 00000000 Import Address Table Directory
Entry d 00000000 00000000 Delay Import Directory
Entry e 00000000 00000000 CLR Runtime Header
Entry f 00000000 00000000 Reserved

There is an import table in .idata at 0x4000

The Import Tables (interpreted .idata section contents)
 vma:            Hint    Time      Forward  DLL       First
                 Table   Stamp     Chain    Name      Thunk
 00003000	00000000 00000000 00000000 00000000 00000000


PE File Base Relocations (interpreted .reloc section contents)

Virtual Address: 00001000 Chunk size 12 (0xc) Number of fixups 2
	reloc    0 offset    2 [1002] LOW
	reloc    1 offset    0 [1000] ABSOLUTE

private flags = 820: [APCS-32] [floats passed in integer registers] [absolute position] [interworking not supported]

$ 

-- so the 16-bit COFF ARM_16 relocation has been indeed converted to an 
IMAGE_REL_BASED_LOW fixup.  And with my original patch applied we instead 
get:

$ arm-pe-ld -image-base=0x1000 -o short.exe short.o
arm-pe-ld: error: 16-bit reloc in dll
$ 

so it would be a regression.  I think this means we do want these test 
cases along with this change after all.

> >  Apologies to take so long, however I prefer things to be done properly, 
> > even if it requires extra effort.  It's just the way I am, and then this 
> > approach helps preventing technical debt from accumulating.
> 
> I actually appreciate the desire to be thorough.

 So do I your vigilance on this occasion!

 I'll post v3 shortly with the commit description updated accordingly and 
test cases added; it doesn't seem a big deal to prepare this.

  Maciej