[PATCH] ld/PE: Handle MS style import libraries for files named *.exe too

[Martin Storsjö]

On Mon, 11 Nov 2024, Jan Beulich wrote:

> On 11.11.2024 13:27, Martin Storsjö wrote:
>> On Mon, 11 Nov 2024, Jan Beulich wrote:
>>
>>>> Another alternative would be to invert the condition - skipping this for
>>>> any member which is named *.o, which should cover practically all the GNU
>>>> import libraries (and also skipping it if it doesn't contain .idata
>>>> sections). But that's only marginally better than the current solution,
>>>> looking for *.dll and/or *.exe.
>>>
>>> Checking for *.o wouldn't be any better. No file name checks whatsoever
>>> will be.
>>
>> I agree that file name based checks are not ideal - but given the actual
>> potential static libraries that exist, it would be a less problematic file
>> name based check.
>>
>> For regular static libraries, they commonly contain files named *.o. The
>> same goes for the import libraries generated by GNU tools. To be
>> marginally more generic, we could also extend it to cover *.obj which
>> would be static libraries produced by MSVC toolchains.
>>
>> However the MSVC style import libraries contain members named *.dll,
>> *.exe, *.drv, etc.
>>
>> Therefore, I think that enumerating the file name extensions of regular
>> object files, *.o and *.obj, is easier than enumerating the potential file
>> name extensions in the MSVC style import libraries.
>>
>> And as long as we still have a check for "object file contains .idata
>> sections", the only critical case to cover is the other cases that do
>> fulfill this condition, i.e. import libraries produced by GNU tools, which
>> contain members named *.o.
>
> Okay, let's go this route then, unless someone else chimes in with a yet
> better approach.

Ok, I'll try to update the patch in that fashion, then.

>>> However, for Windows-style libraries actual section contents (and
>>> relocations) are "manufactured" by pe_ILF_build_a_bfd(). Can't that flag
>>> the resulting bfd-s in some way, to at least mostly eliminate the need
>>> for heuristics?
>>
>> No, that wouldn't suffice - because the ILF form MS import libraries also
>> contain a handful of regular COFF object files (for the header/trailer).
>
> Right, hence me having said "mostly".
>
>>> Then again that wouldn't cover the non-ILF form that MS also used ages
>>> ago (which I expect you mean when talking about GNU format import
>>> libraries), where this (admittedly odd) re-ordering would also appear to
>>> be necessary.
>>
>> TBH, I've read about MS using this form as well, but the oldest MSVC I've
>> tried was 6.0 from 1998, and that one already used the new/modern format.
>> It's possible to get access to older versions to inspect them, but I
>> haven't yet set that up.
>
> It took me a while, but I managed to find one single library from 1996
> that was still using the original form.

Oh, interesting. I guess that it can be possible to find tools that 
produce such libraries then, by just digging a couple years further back 
from what I've used so far.

>>> I wonder how LINK.EXE actually manages to get the objects / section
>>> constituents correctly ordered. The numbering of the sub-portions of the
>>> section (.idata$2 etc) alone doesn't look to be sufficient (when pretty
>>> clearly that must have been the original goal).
>>
>> Yeah I'm not entirely sure how they do it either (and I haven't tried
>> reverse engineering it); for the old style files they clearly seem to be
>> sorting things based on archive member name just like GNU ld does, but I'm
>> not sure what heuristics they use for the ILF style files, for sorting the
>> headers/trailers correctly.
>
> I've been wondering whether there's some sorting-by-name involved, seeing
> the "funny" 0x7f character starting all *_NULL_THUNK_DATA symbols.

Hmm, interesting idea! Although sorting sections based on the symbol names 
feels a bit weird, but I guess it's plausible that it works as some sort 
of marker.

// Martin