Dan, The fix looks good for me.
-Dmitry On 2014-11-15 00:30, Daniel D. Daugherty wrote: >> I presume I don't need to sent out another webrev... > > I have to change my mind on this because this fix needs to be > backported to JDK8u-hs-dev. > > Here's the updated JDK9 webrev: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/ > > And here's the JDK8u-hs-dev backport: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/ > > Because of improvements to the JDK9 makefiles, a bunch of the > anchor text has changed. The best way to sanity check the backport > is to download the two patch files and look at them in your favorite > diff tool: > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/hotspot.patch > > http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk8u-hs-dev/8033602_for_jdk8u_hs_dev.patch > > > I need just one sanity check on the backport... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > On 11/13/14 11:18 AM, Daniel D. Daugherty wrote: >> Magnus, >> >> Thanks for the review! >> >> Replies embedded below... >> >> On 11/13/14 7:44 AM, Magnus Ihse Bursie wrote: >>> On 2014-11-11 01:00, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >>>> Yes, it is a small fix, but it is in Makefiles so feel free to >>>> run screaming from the room... :-) On the plus side the fix does >>>> delete two work around source files (Coleen would say that's a >>>> Good Thing (TM)!) >>> >>> ... but you're only deleting the make files? >> >> Good catch! Looks like when I resurrected this fix from my JDK8 >> queue I missed a couple of deletes. >> >> >>> src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c and >>> src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c >>> could be deleted as well, right? >> >> Yes, these should be deleted and I'll do that in this fix. >> Since these are two deletes of files that can no longer be >> built anyway, I presume I don't need to sent out another >> webrev... >> >> >>> >>> Good idea for the fix, anyway. I opened >>> https://bugs.openjdk.java.net/browse/JDK-8064808 to implement a >>> similar solution in configure. >> >> Sounds good to me. >> >> Dan >> >> >>> >>> /Magnus > > > > On 11/10/14 5:00 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a Solaris Full Debug Symbols (FDS) fix ready for review. >> Yes, it is a small fix, but it is in Makefiles so feel free to >> run screaming from the room... :-) On the plus side the fix does >> delete two work around source files (Coleen would say that's a >> Good Thing (TM)!) >> >> The fix is to detect the version of GNU objcopy that is being >> used on the machine and only enable Full Debug Symbols when that >> version is 2.21.1 or newer. If you don't have the right version, >> then the build drops back to pre-FDS build configs with a message >> like this: >> >> WARNING: /usr/sfw/bin/gobjcopy --version info: >> WARNING: GNU objcopy 2.15 >> WARNING: an objcopy version of 2.21.1 or newer is needed to create > valid .debuginfo files. >> WARNING: ignoring above objcopy command. >> WARNING: patch 149063-01 or newer contains the correct Solaris 10 > SPARC version. >> WARNING: patch 149064-01 or newer contains the correct Solaris 10 X86 > version. >> WARNING: Solaris 11 Update 1 contains the correct version. >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 >> >> This work is being tracked by the following bug IDs: >> >> JDK-8033602 wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC >> https://bugs.openjdk.java.net/browse/JDK-8033602 >> >> JDK-8034005 cannot debug in synchronizer.o or objectMonitor.o on > Solaris X86 >> https://bugs.openjdk.java.net/browse/JDK-8034005 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8033602-webrev/0-jdk9-hs-rt/ >> >> Testing: >> >> - JPRT test jobs to verify that the current JPRT Solaris hosts >> are happy >> - local builds on my Solaris 10 X86 machine to verify that the >> wrong version of GNU objcopy is caught >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
