[PATCH] Windows 32-bit DLL name decoration
Alexey Ivanov
alexey.ivanov at oracle.com
Wed Dec 12 15:34:18 UTC 2018
On 12/12/2018 12:58, Magnus Ihse Bursie wrote:
>
>
> On 2018-12-12 12:35, Alan Bateman wrote:
>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
>>> :
>>>
>>> I searched the code for "jdwpTransport_On" to see of there was any
>>> corresponding OnUnload function (or other), but could not find any.
>> That's right, an unload wasn't needed when that SPI was originally
>> added but could be added in the event that some future debugger agent
>> need it. The SPI is a supported/documented JDK-specific mechanism,
>> its "spec" is hosted here:
>>
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html
>>
> ... yet in all that time, we have not fully supported the spec on
> Windows 32. :-( (We never discovered this because of lack of testing,
> I presume, and that our internal usage empoyed a questonable workaround.)
The spec does not specify whether the mangled name should be exported or
not (for Windows 32 bit).
I looked through JNI specification and have found no mention of
JNIEXPORT or JNICALL.
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html
This example uses extern "C" modifier but neither JNIEXPORT or JNICALL:
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments
>
>>
>> I see this thread is touching on the functions exported by libjli.
>> This library is part of the launcher and shouldn't be used directly
>> by anything outside of the JDK. However we have to be careful because
>> JavaFX `javapackager` tool has been using it. There's a JEP to bring
>> a similar tool, jpackage in the current proposal, that will supersede
>> it but in the mean time we need to be careful not to break it. A
>> second issue is that the libjli is listed in the property list
>> (Info.plist) on macOS. This came from Apple in 7u4 and periodically
>> things show up that are using it, e.g. that recent breakage with
>> Eclipse that was never fully diagnosed but we think it was using
>> Info.plist.
> The latest patch, as suggested, will not modify JLI, but instead fix
> the broken behaviour of JDWP on Windows 32.
Yes, that's right.
However, I believe the previous versions did not modify libjli.
Regards,
Alexey
>
> /Magnus
More information about the serviceability-dev
mailing list