URGENT code review request for Solaris FDS fix (7175255)

[Kelly O'Hair]

And TOPDIR might be a variable used in the top level JDK Makefiles, referring to the top of the forest. :^(
So the TOPDIR name needs to be more unique I think.

-kto

On Jun 19, 2012, at 7:06 PM, David Holmes wrote:

> Hi Dan,
> 
> It would be nice if the cd into the 64 directory could be handled internally to the link logic rather than occurring at the top-level (I say this as someone who will need to hand merge this into another workspace ;-) ).
> 
> Also in make/solaris/makefiles/add_gnu_debuglink.make I don't understand the logic change:
> 
> GENERATED                 = ../generated
> 
> becomes
> 
> TOPDIR                    = $(shell echo `pwd`)
> GENERATED                 = $(TOPDIR)/../generated
> 
> but at what time is "pwd" evaluated? If we have: /out/lib/64 and originally we started in lib then GENERATED==lib/../generated ie out/generated. If we have now done a cd into 64 then: pwd = /out/lib/64 and so GENERATED==/out/lib/64/../generated ie /out/lib/generated. I may well be missing something but this doesn't seem right.
> 
> David
> -----
> 
> On 20/06/2012 11:21 AM, Daniel D. Daugherty wrote:
>> Greetings,
>> 
>> This is an URGENT code review request for a Solaris specific Full Debug
>> Symbols (FDS) fix. Due to a Makefile logic error, the full debug symbol
>> files and related '_g' symlinks are created in the wrong sub-directory
>> for a couple of the dtrace libraries. The incorrect paths have a double
>> "64/" sub-directory, e.g.:
>> 
>> solaris-<arch>/jre/lib/<arch>/client/64/64/libjvm_db.debuginfo
>> 
>> These are the correct symlink paths:
>> 
>> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_db.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_dtrace.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_db.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_dtrace.debuginfo
>> 
>> and these are the correct debug info file paths:
>> 
>> solaris-<arch>/jre/lib/<arch>/client/64/libjvm_db.debuginfo
>> solaris-<arch>/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo
>> solaris-<arch>/jre/lib/<arch>/server/64/libjvm_db.debuginfo
>> solaris-<arch>/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_db.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_db.debuginfo
>> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo
>> 
>> where "<arch>" is "i586" or "sparc". The 64-bit Solaris platforms ("amd64"
>> and "sparcv9") don't have this issue because they don't have the "64/"
>> sub-directories.
>> 
>> This fix is targeted at HSX-24/JDK8 and HSX-23.2/JDK7u6 and will resolve
>> an issue that is preventing Oracle's Release Engineering scripts from
>> running properly.
>> 
>> Here is the webrev URL for the HSX-24/JDK8 version:
>> 
>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7175255-webrev/0/
>> 
>> The HSX23.3/JDK7u6 version is the same except for the changes to
>> make/solaris/makefiles/defs.make which are not needed in HSX23.2.
>> 
>> Thanks, in advance, for any reviews!
>> 
>> Dan