Home Original page

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

Jan Beulich jbeulich@suse.com
Fri Nov 8 11:45:32 GMT 2024 
On 07.11.2024 13:21, Martin Storsjö wrote:
> On Thu, 7 Nov 2024, Jan Beulich wrote:
> 
>> On 06.11.2024 10:31, Martin Storsjö wrote:
>>> When handling MS style import libraries (also called short import
>>> libraries, or ILF), we need to detect the kind of library.
>>>
>>> So far, this has been done by looking at the member file names
>>> in the import library - in an MS style import library, all the
>>> member files for a specific library have the same member file
>>> name - the name of the runtime module to link against. Usually
>>> this is a DLL - thus we do a case insensitive comparison and
>>> check if the suffix is .dll.
>>>
>>> However, an .exe can also export symbols which can be linked
>>> against in the same way. In particular, if linking against
>>> WDK (Windows Driver Kit) import libraries, e.g. wdmsec.lib, the
>>> import libraries can provide imports for ntoskrnl.exe.
>>>
>>> Thus extend the preexisting check from checking for the .dll
>>> suffix to also checking for .exe. While this isn't entirely
>>> complete and scalable (in theory, such libraries could have
>>> any suffix), this should cover a larger majority of them.
>>
>> How difficult would it be to remove this dependency on file name
>> extensions? I really don't like going from 1 to 2, when - as you
>> validly say - any can be used. Just think of drivers, using .drv.
> 
> I haven't fully thought it through, but I think it's unfortunately less 
> easy than it seems on first glance.
> 
> For the long import libraries that GNU tools generate, the import 
> libraries consist of a bunch of files named <common_base><suffix>.o - all 
> of these are regular object files.
> 
> For the MS import libraries, all member file names are named the same, 
> e.g. "kernel32.dll". Most of them (for each imported symbol) aren't object 
> files, but the special short import file format, and it should be simple 
> to detect this just by looking at the contents of the files. But for the 
> header and trailer object files, those are plain regular object files, 
> just like in the long import libraries.
> 
> So for the individual symbols, we can easily detect this, but for 
> headers/trailers, we don't see anything different than just regular object 
> files.

Is that really the case? Would an ordinary object file ever have (non-
empty, i.e. not just marker) .idata$<N> sections? IOW can't the file
name check simply be dropped, relying on

		/* An archive member named .dll, but not having any .idata
		   sections - apparently not a Microsoft import object
		   after all: Skip renaming it.  */
		if (!idata)
		  continue;

in the middle of the loop instead (with the comment adjusted)?

Talking of comments - if your change was the one to go in, it'll also need
to update those comments talking of .dll.

Jan
More information about the Binutils mailing list