URGENT code review request for Solaris FDS fix (7175255)

[Daniel D. Daugherty]

TOPDIR is also used in other HotSpot Makefiles so my usage here
is consistent.

Dan


On 6/19/12 8:51 PM, Kelly O'Hair wrote:
> 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