[PATCH] Windows 32-bit DLL name decoration

[Simon Tooke]

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.
>