RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Staffan Larsen]

On 17 aug 2013, at 01:04, Tim Bell <tim.bell at 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 at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130818/282fcffb/attachment.html