RFR: 8033580: Old debug information in IMPORT_JDK is not removed

[Daniel D. Daugherty]

 > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/

make/Makefile

+      ifeq ($(OSNAME), bsd)
+            $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM

The above needs to be:

        ifeq ($(OS_VENDOR), Darwin)
              $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM

I don't think that BSD uses .dylib stuff; that's MacOS X specific.

Dan


On 2/13/14 1:59 PM, Erik Helin wrote:
> Hi Dan,
>
> thanks for reviewing! See my replies inline.
>
> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote:
>>  > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/
>>
>> make/Makefile
>>      277   ifeq ($(ZIP_DEBUGINFO_FILES),1)
>>      278     ifeq ($(OSNAME), windows)
>>      279           $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map
>> $(EXPORT_SERVER_DIR)/jvm.pdb
>>      280     else
>>      281           $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo
>>      282     endif
>>
>>      On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so
>>      you'll need a MacOS X specific rule. You don't need an
>>      update for the JVM_VARIANT_CLIENT version because MacOS X
>>      doesn't support the Client VM, but if it did...
>
> Thanks for catching this! I've uploaded a new webrev at:
> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/
>
> The same testing was done as for the first patch.
>
> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote:
>> So the above change handles libjvm, but what about the
>> other libraries exported by HotSpot? libjsig, libjvm_db,
>> and libjvm_dtrace come to mind...
>
> As we discussed, I would like to implement this for libjvm first and 
> then take care of the other libraries in a separate patch.
>
> Thanks,
> Erik
>
>> Dan
>>
>>
>> On 2/12/14 8:03 AM, Erik Helin wrote:
>>> Hi all,
>>>
>>> this patch changes how old debug information copied from IMPORT_JDK is
>>> treated.
>>>
>>> When running the copy_*_jdk target, HotSpot's makefiles copies the
>>> entire IMPORT_JDK folder, including additional files (such as unzipped
>>> debug information). The export_*_jdk targets will then, via the
>>> generic_export target, copy the build artifacts via implicit rules to
>>> the correct destination in hotspot/build/JDK_IMAGE_DIR.
>>>
>>> The bug arises when IMPORT_JDK contains unzipped debug info
>>> (libjvm.debuginfo) and the make target produces zipped debug info
>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then
>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them
>>> will match libjvm.so.
>>>
>>> Finally, the JPRT make targets jprt_build_* just zips
>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up
>>> having different zipped and unzipped debug info, since the IMPORT_JDK
>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by default.
>>>
>>> This patch removes the debug info that we did *not* build. If we build
>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists).
>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be
>>> removed (if it exists).
>>>
>>> Patch:
>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8033580
>>>
>>> Testing:
>>> - Building in JPRT
>>> - Building Linux 32-bit locally on a Linux 64-bit machine
>>> - Building Linux 64-bit locally on a Linux 64-bit machine
>>>
>>> For all of the above, verify that only the correct debug info is
>>> present in the output.
>>>
>>> Thanks,
>>> Erik
>>