[PATCH] Add support for IMPORT_NAME_EXPORTAS in ILF (MSVC style) import libraries

[Martin Storsjö]

On Tue, 1 Oct 2024, Jan Beulich wrote:

> On 01.10.2024 08:54, Martin Storsjö wrote:
>> On Tue, 1 Oct 2024, Jan Beulich wrote:
>>
>>> On 30.09.2024 23:00, Martin Storsjö wrote:
>>>> This import name type is formally yet undocumented, but MSVC
>>>> produces/supports it, primarily for ARM64EC import libraries.
>>>>
>>>> LLVM/LLD also supports this import name type. Since recently,
>>>> llvm-dlltool also uses this type for certain kinds of renamed imports
>>>> (that are easy to do in the long style import libraries produced by
>>>> GNU dlltool, but require this name type in short import libraries).
>>>>
>>>> This name type contains a third string, in addition to the symbol
>>>> name and the DLL name, indicating the actual imported name to
>>>> reference in the import tables - which now can be distinct different
>>>> from the symbol name on the object file level.
>>>
>>> The change looks plausible for what is described above, yet even if the
>>> form is formally undocumented, some kind of reference must exist
>>> somewhere. Such a reference is imo quite relevant to have here.
>>
>> Sure;
>> https://github.com/llvm/llvm-project/commit/8f23464a5d957242c89ca6f33d4379c42519cd81
>> and
>> https://github.com/llvm/llvm-project/commit/7b275aa2438c22604505d618dd37ee60052f2800
>> show how the same import name type was added in LLVM; those two are
>> probably the first public references to the type.
>>
>> I can amend the commit message to reference these.
>
> Please do. Then together with ...
>
>>>> --- a/include/coff/pe.h
>>>> +++ b/include/coff/pe.h
>>>> @@ -338,6 +338,7 @@ typedef struct
>>>>  #define IMPORT_NAME		1
>>>>  #define IMPORT_NAME_NOPREFIX	2
>>>>  #define IMPORT_NAME_UNDECORATE	3
>>>> +#define IMPORT_NAME_EXPORTAS    4
>>>
>>> Please use tab padding here, just like the neighboring lines do.
>>
>> Oh, oops, I tried to get that consistent for the code, but I missed this
>> one. Will amend the commit with that change.
>
> ... this adjustment okay to put in.

Thanks! I'll push the commit later today or tomorrow then, to let others 
comment, in case there is further feedback.

// Martin