On 08/16/13 09:51 AM, Staffan Larsen wrote:
This failure happens when compiling with the VS 2012 compiler. The attach code
relies on the order of two methods in the compiled binary and VS 2012 changed
that order. The solution used is the linker flag /ORDER [1] which allows us to
specify the order in which methods are laid out in the binary image. Since the
flag only operates on non-static methods, the methods have been made non-static
and also changed name so that they will not clash with other methods.
webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
The change has been tested with both VS 2010 and VS 2012.
Thanks,
/Staffan
[1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
makefiles/CompileNativeLibraries.gmk
No comments
src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
Are these method names part of any public API? If not, never mind. If
so, changing names like thread_func to jvm_attach_thread_func could
surprise some users and require a CCC request...
makefiles/mapfiles/libattach/reorder-windows-x86
line 1: jvm_attach_thread_func@4
Is that @4 correct? I do not see it in the _64 version of the file -
just wondering...
makefiles/mapfiles/libattach/reorder-windows-x86_64
No comments
Tim
