URGENT code review request for Solaris FDS fix (7175255)

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Jun 20 04:50:28 UTC 2012


On 6/19/12 10:36 PM, David Holmes wrote:
> 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.

TOPDIR is set to `pwd` once when the add_gnu_debuglink.make file
is included into vm.make.

The ADD_GNU_DEBUGLINK variable is only set once. Its value does
not change every time it is called.

Dan

>
> 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



More information about the build-dev mailing list