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


Reply via email to