URGENT code review request for Solaris FDS fix (7175255)

[David Holmes]

On 20/06/2012 2:32 PM, Daniel D. Daugherty wrote:
>> That all said, it still seems to me that the logic for GENERATED is
>> not correct if you have done a cd into the 64 subdirectory.
>
> Exactly the opposite is true. Without the TOPDIR/GENERATED combo,
> when you "cd 64", the "../generated" that the GENERATED variable
> resolves to no longer works. When GENERATED is set to
> "$(TOPDIR)/../generated", then it becomes an absolute path that
> can be used anywhere...

Yes but "pwd" changes which in turn changes the path to generated. So I 
don't see how this works - I assume generated is not moving and that we 
don't have multiple generated directories.

Anyway let's defer further discussion to the updated webrev.

David

> However, I think where this is going to end up is something like:
>
> - add TOPDIR only to add_gnu_debuglink.make
> - set the ADD_GNU_DEBUGLINK variable using TOPDIR and a
> literal "../generated/add_gnu_debuglink"
> - don't set GENERATED in add_gnu_debuglink.make at all
> - drop the changes to fix_empty_sec_hdr_flags.make
>
> I think that'll reduce the risk since this fix needs to
> go back to HSX23.2 and HSX24.
>
> Dan
>
>
>>
>> Cheers,
>> David
>>> Dan
>>>
>>>
>>>
>>>>
>>>> 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