On 17 aug 2013, at 01:04, Tim Bell <tim.b...@oracle.com> wrote: > 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...
No they are not public. They used be declared "static" which implies that they couldn't be see by anyone else. > > 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... Yes, the @4 is the only difference between the files. It wasn't for that, I would be using the same file on both platforms. The @4 comes from the way the compiler mangles names. > > > makefiles/mapfiles/libattach/reorder-windows-x86_64 > > No comments > > Tim > Thanks, /Staffan
