Forgot to add the link:
On 12/12/2018 16:10, Alexey Ivanov wrote:
Ali has scanned the code base, he says, “couldn’t find (hopefully tbh)
other occurrences of such mismatches.”
http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024358.html
On 10/12/2018 10:45, Magnus Ihse Bursie
Thank you, Ali, for doing this!
On 10/12/2018 21:13, Ali İnce wrote:
Hi Alexey,
I’ve searched for |GetProcAddress| usages across source code and
couldn’t find (hopefully tbh) other occurrences of such mismatches.
Regards,
Ali
Ali has scanned the code base, he says, “couldn’t find (hopefully tbh)
other occurrences of such mismatches.”
On 10/12/2018 10:45, Magnus Ihse Bursie wrote:
It might be worthwhile to scan the entire code base for JNICALL and
verify that we have no more mismatches. In general, JNICALL should be
Hi Alexey,
I’ve searched for |GetProcAddress| usages across source code and couldn’t find
(hopefully tbh) other occurrences of such mismatches.
Regards,
Ali
> On 7 Dec 2018, at 20:24, Alexey Ivanov wrote:
>
> Hi Ali,
>
> On 06/12/2018 22:49, Ali İnce wrote:
>> Hi Magnus, Alexey,
>>
>> I be
On 2018-12-07 21:24, Alexey Ivanov wrote:
Hi Ali,
On 06/12/2018 22:49, Ali İnce wrote:
Hi Magnus, Alexey,
I believe we won’t be able to get further opinions from
serviceability-dev.
Unfortunately, no one has replied as of now.
Have you found any issues with jdwpTransport_OnLoad after remo
Hi Ali,
On 06/12/2018 22:49, Ali İnce wrote:
Hi Magnus, Alexey,
I believe we won’t be able to get further opinions from
serviceability-dev.
Unfortunately, no one has replied as of now.
Have you found any issues with jdwpTransport_OnLoad after removing JNICALL?
Andrew Luo suggested using a s
Hi Magnus, Alexey,
I believe we won’t be able to get further opinions from serviceability-dev.
Andrew Luo suggested using a similar mechanism as is used for jvm.dll by using
symbol name files mapped by platform (files are under make/hotspot/symbols and
interestingly windows is almost the only p
I think we are in complete agreement. What's missing is some expert opinion
from serviceability-dev if there is any problem with changing the signature.
I'd preferably have that.
If no one knows, I'd say, change it, and see if we still pass the relevant
tests, and if so, ship it.
/Magnus
>
On 21/11/2018 12:16, Magnus Ihse Bursie wrote:
On 2018-11-20 16:49, Alexey Ivanov wrote:
Hi Ali, Magnus,
I absolutely agree this change has to be reviewed by someone from
serviceability.
There are several options:
1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows
http://mail.ope
On 2018-11-20 16:49, Alexey Ivanov wrote:
Hi Ali, Magnus,
I absolutely agree this change has to be reviewed by someone from
serviceability.
There are several options:
1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/02
Hi Alexey, Magnus,
Thanks for all of your comments on the possible options.
Another option would be to use def files which contain an EXPORTS section
that lists the exported functions (
https://docs.microsoft.com/en-gb/cpp/build/reference/exports?view=vs-2017).
These files can lie next to the nat
Hi Ali, Magnus,
I absolutely agree this change has to be reviewed by someone from
serviceability.
There are several options:
1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html
so it partially reverts the change
Hi Ali,
I have submitted a JBS issue for you:
https://bugs.openjdk.java.net/browse/JDK-8214122
“Prevent name mangling of jdwpTransport_OnLoad in dt_socket and dt_shell
dynamic link libraries”
Let me know if I got any details wrong.
I've left the bug unassigned. Once reviewed, I can sponsor yo
13 matches
Mail list logo
