RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005

[Daniel D. Daugherty]

 > 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