[PATCH v2 06/13] LD/PE: Remove remains of MIPS target support
Maciej W. Rozycki
macro@orcam.me.uk
Tue Oct 7 20:33:05 GMT 2025
On Mon, 8 Sep 2025, Jan Beulich wrote:
> > In this case I haven't had an opportunity yet to investigate your
> > reference and offhand keeping a piece of code only to satisfy "invalid
> > usage" does not appear justified. I've run out of time and please mind I
> > do it outside my day job. Besides, dead code being removed here has been
> > in this state for 20+ years now, so there's no need rushing its removal.
> > World just won't collapse if this code stays there for another fortnight.
>
> Well, I can certainly remove the patch from my series again, as it doesn't
> strictly depend on it. But having the tidying go in first seemed preferable
> to me, hence why I had hoped for your change to have gone in quite some
> time ago. As it didn't, I decided to include it with - and that's imo the
> important part - merely applying the review comment I gave. Nothing rude in
> here, I don't think.
>
> Removing dead code is of course always desirable. Removing code which
> cannot be proven to be dead, otoh, may not be.
I took some time now to get to the bottom of it and my findings indicate
that no PE target currently supported has COFF relocations that match the
`BITS_AND_SHIFT (16, 16)' selector, so this part of the switch statement
can go right away with no doubt.
Then these are the COFF relocations that match `BITS_AND_SHIFT (16, 0)'
and are neither PC-relative nor section ones (which are excluded for the
code block in question, as you can see with the enclosing conditional `if'
statement):
- ARM: ARM_16,
- i386: R_RELWORD aka 16,
- x86_64: R_RELWORD aka R_X86_64_16.
So these could potentially be converted by LD to image relocations (which
is the PE-speak term for dynamic relocations; sometimes also referred to
as image fixups), whether it makes sense or not.
For the record: PE image relocations do not refer to a symbol and are
akin to ELF relative dynamic relocations applied to local GOT entries in
numerous psABIs. It is why they all have a _BASED_ infix in their names:
to denote that they are just base-related fixups.
Let's try to use them then:
$ cat long.s
.data
.globl foo
foo:
.dc.l 0
.dc.l foo
$ arm-pe-as -o long.o long.s
$ arm-pe-objdump -r long.o
long.o: file format pe-arm-little
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000004 ARM_32 foo
$ arm-pe-ld -o long.exe long.o
$ arm-pe-objdump -p long.exe
long.exe: file format pei-arm-little
Characteristics 0x306
executable
line numbers stripped
32 bit words
debugging information removed
Time/Date Tue Oct 7 20:49:29 2025
Magic 010b (PE32)
MajorLinkerVersion 2
MinorLinkerVersion 45
SizeOfCode 00000000
SizeOfInitializedData 00000600
SizeOfUninitializedData 00000000
AddressOfEntryPoint 00001000
BaseOfCode 00000000
BaseOfData 00001000
ImageBase 00010000
SectionAlignment 00001000
FileAlignment 00000200
MajorOSystemVersion 4
MinorOSystemVersion 0
MajorImageVersion 1
MinorImageVersion 0
MajorSubsystemVersion 3
MinorSubsystemVersion 0
Win32Version 00000000
SizeOfImage 00005000
SizeOfHeaders 00000400
CheckSum 00009b5d
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 0x13000
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 4 [1004] HIGHLOW
reloc 1 offset 0 [1000] ABSOLUTE
private flags = 820: [APCS-32] [floats passed in integer registers] [absolute position] [interworking not supported]
$
So here we have a 32-bit COFF ARM_32 relocation that's been converted to
an IMAGE_REL_BASED_HIGHLOW fixup. Let's try a 16-bit relocation instead:
$ cat short.s
.data
.globl foo
foo:
.dc.w 0
.dc.w foo
$ arm-pe-as -o long.o long.s
$ arm-pe-objdump -r long.o
short.o: file format pe-arm-little
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000002 ARM_16 foo
$ 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.
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.
FWIW, none of these COFF relocations are in the PE specification[1],
which has gaps in the definitions, so presumably they're only supposed to
be used with some *nix targets or suchlike, perhaps 16-bit ones.
> >> And then, can you please indicate when (approximately) this is going to be?
> >
> > I'm back now, but I've run out of time this week too. I'll try to get to
> > it Mon-Wed next week. I'll appreciate your understanding.
>
> I appreciate this, yet as I'm going to travel from end of this week, I won't
> commit my series ahead of that anymore, as I wouldn't be able to deal with
> eventual fallout in a timely manner. Hence it'll now be delayed by another
> month ...
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 request that my original patch as posted[2] be approved then.
I'll see if I can convert the recipes given above to a bunch of proper
test cases, as we have little to no coverage here (or we wouldn't have to
scratch our heads over this here), but it doesn't appear a prerequisite to
me for my dead MIPS code removal change. Please feel free to beat me to
it. I wish people were more thorough in accompanying their contributions
with suitable test cases.
References:
[1] "Microsoft Portable Executable and Common Object File Format
Specification", Microsoft Corporation, Revision 11 -- January 23, 2017
[2] "LD/PE: Remove remains of MIPS target support",
<https://patchwork.sourceware.org/project/binutils/patch/alpine.DEB.2.21.2508071431150.10467@angie.orcam.me.uk/>
Maciej
More information about the Binutils
mailing list