[PATCH] Windows 32-bit DLL name decoration

[Magnus Ihse Bursie]

On 2018-12-11 18:22, Bob Vandette wrote:
> Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad
> functions.  Perhaps you should just follow the same procedure for the debug
> library.
>
> #define JNI_ONLOAD_SYMBOLS   {"_JNI_OnLoad at 8", "JNI_OnLoad"}
> #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"}
> #define JVM_ONLOAD_SYMBOLS      {"_JVM_OnLoad at 12", "JVM_OnLoad"}
> #define AGENT_ONLOAD_SYMBOLS    {"_Agent_OnLoad at 12", "Agent_OnLoad"}
> #define AGENT_ONUNLOAD_SYMBOLS  {"_Agent_OnUnload at 4", "Agent_OnUnload"}
> #define AGENT_ONATTACH_SYMBOLS  {"_Agent_OnAttach at 12", “Agent_OnAttach”}
Yes, that sounds mostly reasonable. The latest iteration of the patch is 
doing just this.

I searched the code for "jdwpTransport_On" to see of there was any 
corresponding OnUnload function (or other), but could not find any. But 
if there are other *_OnEvent() functions in the JDK code, they should be 
fixed too to handle decorated names. To the best of my knowledge, 
jdwpTransport_OnLoad was the only such *_OnEvent function that did not 
handle decorated names. I searched the code base for the pattern 
'[a-zA-Z]+_On[A-Z][a-zA-Z]*' and skimmed the result, but could not find 
anything else apart from those listed by you above, and the 
jdwpTransport_OnLoad. Any knowledge of additional such functions but 
with different names must come from the component teams.

/Magnus
>
> Bob.
>
>
>> On Dec 11, 2018, at 11:43 AM, Simon Tooke <stooke at redhat.com> wrote:
>>
>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote:
>>> Hi everyone,
>>>
>>> I came up with the following patch:
>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/
>>>
>>> It specifically addresses the problem in JDK-8214122 where on 32 bit
>>> Windows jdwpTransport_OnLoad can exported with its plain and
>>> __stdcall-mangled name. I used conditional compilation so that for
>>> other platforms the code remains as it is now.
>>>
>>> jshell starts successfully with this fix; an IDE debugger works as well.
>>>
>> I am not a reviewer, but this patch only works for the specific case
>> under discussion; the '@16' refers to the reserved stack size in the
>> Pascal calling convention.  So, the patch only works for 16 bytes of
>> parameters.  To be generic, the routine needs to have the stack size
>> passed in by the caller.  If a generic fix isn't desired (and I hope it
>> is), I'd prefer to see the caller simply pass the decorated or
>> undecorated name depending on the Win32/64 defines.
>>
>>     #if defined(_WIN32) && !defined(_WIN64) onLoad =
>>     (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle,
>>     "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t)
>>     dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif
>>
>>
>> Thanks,
>> -Simon
>>
>>> Regards,
>>> Alexey
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8214122
>>>
>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote:
>>>>> Since removing JNICALL is not an option, there are only two options:
>>>>>
>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the
>>>>> source file;
>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32
>>>>> with fallback to undecorated one.
>>>> Yes.
>>>>
>>>> I think the correct solution here is 2.