EVALUATION
http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7d4e6dabc6bf
|
|
|
EVALUATION
http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/7d4e6dabc6bf
|
|
|
EVALUATION
http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7d4e6dabc6bf
|
|
|
SUGGESTED FIX
See the attached 7165060-webrev-cr0.tgz and
7165060-webrev-cr1.tgz for the proposed work around.
Also re-enables FDS on Solaris and ZIP_DEBUGINFO_FILES
on Windows.
|
|
|
EVALUATION
Work around 'gobjcopy --add-gnu-debuglink' failure by adding
a temporary tool that adds the '.gnu_debuglink' section and
nothing more.
|
|
|
EVALUATION
http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7d4e6dabc6bf
|
|
|
EVALUATION
I filed the following Solaris bug for the gobjcopy corruption:
7165526 2/3 gobjcopy corrupts SUNW_dof section in libjvm.so and
breaks dtrace
Work on this bug is blocked until a Solaris 10 patch for gobjcopy
is available.
|
|
|
EVALUATION
Keith says the dtrace cmd relies on the SUNW_dof section that is
added during the libjvm build process. Here's what elfdump shows
libjvm.so.no_strip:
elfdump.no_strip:Section Header[18]: sh_name: .SUNW_dof
elfdump.no_strip: sh_size: 0x249af sh_type: [ SHT_SUNW_dof ]
elfdump.no_strip: [1222] 0x009edadf 0x00000000 OBJT GLOB D 0 .SUNW_dof _etext
elfdump.no_strip: [19] 0x009c9130 0x00000000 SECT LOCL D 0 .SUNW_dof
elfdump.no_strip: [178887] 0x009c9130 0x000249af OBJT LOCL H 0 .SUNW_dof ___SUNW_dof
elfdump.no_strip: [298191] 0x009edadf 0x00000000 OBJT GLOB D 0 .SUNW_dof _etext
Here's what elfdump shows for libjvm.so.debuglink:
elfdump.debuglink:libjvm.so.debuglink: .symtab: bad symbol entry: ___SUNW_dof: section[18] size: 248: is smaller than symbol size: 149935
elfdump.debuglink: [178887] 0x009c9130 0x000249af OBJT LOCL H 0 .dynamic ___SUNW_dof
The SUNW_dof section is gone which is probably not a good thing.
|
|
|
EVALUATION
Just looking at ELF section header names:
$ elfdump -c libjvm.so.no_strip \
| sed -n 's/^Section Header.*sh_name: //p' | sort > g0
$ elfdump -c libjvm.so.debuglink \
| sed -n 's/^Section Header.*sh_name: //p' | sort > g1
$ diff g?
1,3d0
< .SUNW_cap
< .SUNW_dof
< .annotate
19a17
> .gnu_debuglink
|
|
|
EVALUATION
The VM/NSK dtrace tests don't like the libjvm.so file after the
'gobjcopy --add-gnu-debuglink' has been done. Even if the debug
info is left in libjvm.so (no 'strip -x' and no 'gobjcopy
--strip-debug'), just using 'gobjcopy --add-gnu-debuglink' is
enough to make the VM/NSK dtrace tests fail.
I think this means one of two things:
1) the gobjcopy command is corrupting the libjvm.so file
2) the dtrace subsuite is somehow confused by the debug
info link that is added to libjvm.so
|
|
|
Java