From sgehwolf at redhat.com Thu Feb 7 17:09:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Feb 2019 18:09:18 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries Message-ID: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Hi, Could I please get reviews for this enhancement? It adds a debug symbols stripping plug-in to jlink for Linux and Unix platforms. It's the first platform specific jlink plugin and the approach taken for keeping it contained is to use a plugin specific ResourceBundle. Discussion for this happened in [1]. The test uses a native library which should never get debug symbols stripped during the test library build. As such, tiny modifications were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev being on the list for this RFR. The test currently only runs on Linux and requires objcopy to be available. Otherwise the test is being skipped. Example usage of this plugin is described in the bug. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux x86_64 (with good and broken objcopy) and the newly added test. It's currently running through jdk/submit too. Thoughts? Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html From erik.joelsson at oracle.com Thu Feb 7 17:39:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Feb 2019 09:39:09 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Hello Severin, There is a macro for automatically finding all source dirs for a module. So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using that macro, like this: JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) The above could/should even be inlined. Otherwise build changes look ok. /Erik On 2019-02-07 09:09, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this enhancement? It adds a debug > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > the first platform specific jlink plugin and the approach taken for > keeping it contained is to use a plugin specific ResourceBundle. > Discussion for this happened in [1]. > > The test uses a native library which should never get debug symbols > stripped during the test library build. As such, tiny modifications > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > being on the list for this RFR. The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. > > Example usage of this plugin is described in the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux > x86_64 (with good and broken objcopy) and the newly added test. It's > currently running through jdk/submit too. > > Thoughts? > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > From sgehwolf at redhat.com Thu Feb 7 19:09:24 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 Feb 2019 20:09:24 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Message-ID: Hi Erik, On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > Hello Severin, > > There is a macro for automatically finding all source dirs for a module. > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > that macro, like this: > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > The above could/should even be inlined. I've considered this. It seems, though, that FindModuleSrcDirs comes from make/common/Modules.gmk which isn't included in make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused problems with multiple includes of Modules.gmk (JDK-8213736) I was reluctant to include it here too. Without the new include the above won't work. The approach I've taken here seems to be the lesser evil. Thoughts? Thanks, Severin > Otherwise build changes look ok. > > /Erik > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this enhancement? It adds a debug > > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > > the first platform specific jlink plugin and the approach taken for > > keeping it contained is to use a plugin specific ResourceBundle. > > Discussion for this happened in [1]. > > > > The test uses a native library which should never get debug symbols > > stripped during the test library build. As such, tiny modifications > > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > > being on the list for this RFR. The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > > > Example usage of this plugin is described in the bug. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux > > x86_64 (with good and broken objcopy) and the newly added test. It's > > currently running through jdk/submit too. > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > From mandy.chung at oracle.com Thu Feb 7 20:43:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Feb 2019 12:43:06 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: Hi Severin, Using the plugin specific ResourceBundle is good. Thanks for making the change. I see that Alan's comment [1] on the plugin options and I assume you will investigate the plugin options and bring back a proposal. Did I miss the discussion on these options? Option: --strip-native-debug-symbols=][:debuginfo-file-ext=][:include-debug-syms=true]> Examples: --strip-native-debug-symbols=defaults I suggest the above be simplified and drop the "=defaults". Simply: --strip-native-debug-symbols Examples: --strip-native-debug-symbols=options:objcopy-cmd=/usr/bin/objcopy:debuginfo-file-ext=dbg:include-debug-syms=true If include-debug-syms=true then it will run objcopy --only-keep-debug foo foo. to create debug symbols file objcopy --add-gnu-debuglink=foo.dbg foo So what about simplifying the options to: --strip-native-debug-symbols=keep-debug-symbols=dbg,objcopy-path=/usr/bin/objcopy We could also drop the word "symbols": --strip-native-debug=[keep-debug=,][objcopy-path=] By default, `--strip-native-debug` will strip native debug symbols and don't keep debug symbols. keep-debug= creates the debug symbols file. specifies the file extension. It would be nice to use the default `debuginfo` extension and simply accept `keep-debug` option. `objcopy-cmd` may be okay too. Others may have opinion. I think we should agree on the plugin options first before doing the code review. W.r.t. the test: > The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. We can create a fake objcopy utility for testing purpose such that the test will validate if the options are passed properly to the test utility. > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ I haven't reviewed the new files. Just notice that very long lines in the new files that you may want to fix the formatting that will help further side-by-side review. The --list-plugin output is very very long. The existing plugins didn't set a good example to keep the well formatted (I recorded that they were cleaned up at one point to keep 80 chars width). One other question: should this plugin be moved to linux/classes rather than unix/classes given that that's the platform it intends to support? Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014099.html From erik.joelsson at oracle.com Fri Feb 8 01:01:04 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Feb 2019 17:01:04 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> Message-ID: <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> On 2019-02-07 11:09, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> There is a macro for automatically finding all source dirs for a module. >> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >> that macro, like this: >> >> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >> >> The above could/should even be inlined. > I've considered this. It seems, though, that FindModuleSrcDirs comes > from make/common/Modules.gmk which isn't included in > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > problems with multiple includes of Modules.gmk (JDK-8213736) I was > reluctant to include it here too. Without the new include the above > won't work. > > The approach I've taken here seems to be the lesser evil. Thoughts? I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, which is part of where Modules.gmk gets bootstrapped. In any normal makefile (as in where stuff is just being built), the bootstrapping is done and including Modules.gmk is completely fine. Any -.gmk file certainly qualifies here. /Erik > Thanks, > Severin > >> Otherwise build changes look ok. >> >> /Erik >> >> On 2019-02-07 09:09, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get reviews for this enhancement? It adds a debug >>> symbols stripping plug-in to jlink for Linux and Unix platforms. It's >>> the first platform specific jlink plugin and the approach taken for >>> keeping it contained is to use a plugin specific ResourceBundle. >>> Discussion for this happened in [1]. >>> >>> The test uses a native library which should never get debug symbols >>> stripped during the test library build. As such, tiny modifications >>> were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev >>> being on the list for this RFR. The test currently only runs on Linux >>> and requires objcopy to be available. Otherwise the test is being >>> skipped. >>> >>> Example usage of this plugin is described in the bug. >>> >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>> >>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on Linux >>> x86_64 (with good and broken objcopy) and the newly added test. It's >>> currently running through jdk/submit too. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >>> >>> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>> From Alan.Bateman at oracle.com Fri Feb 8 10:08:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Feb 2019 10:08:21 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: On 07/02/2019 17:09, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this enhancement? It adds a debug > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > the first platform specific jlink plugin and the approach taken for > keeping it contained is to use a plugin specific ResourceBundle. > Discussion for this happened in [1]. > > The test uses a native library which should never get debug symbols > stripped during the test library build. As such, tiny modifications > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > being on the list for this RFR. The test currently only runs on Linux > and requires objcopy to be available. Otherwise the test is being > skipped. > > Example usage of this plugin is described in the bug. > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > I agree with Mandy that the CLI options need examination. The proposed `--strip-native-debug-symbols` seems reasonable but it will be inconsistent with the existing `--strip-debug` option. Mandy - what you would think about renaming the existing option to something that makes it clear that it strips the debug attribute from class files? (we would of course need to do something to keep the existing option working). The need to specify the argument as "defaults" or "options" is a bit annoying. It might be time to replace hasArguments in the plugin interface to allow for optional arguments. The plugin interface is not exported/documented/supported so we have flexibility to change it. If we do this then it should mean the usages reduce down to: --strip-native-debug-symbols --strip-native-debug-symbols objcopy=:... I see the plugin has moved to src/jdk.jlink/unix in this iteration. It might be better to start out in src/jdk.jlink/linux - we can always move to the unix tree in the event that there is interest/support on other platforms. Mandy points out the issue with wrapping in the usage output. I agree that the`jlink --list-plugins` needs to be readable/tidy esp. in this case as there are many sub-options to read about. The implementation will need a bit of a tidy up too. The readFileBytes method can be replaced with Files.readAllBytes. The BAIS usage can be replaced with Files.write. Ignoring exceptions thrown in stripBinary will also need consideration. -Alan From mandy.chung at oracle.com Fri Feb 8 18:53:34 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Feb 2019 10:53:34 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> On 2/8/19 2:08 AM, Alan Bateman wrote: > I agree with Mandy that the CLI options need examination. The proposed > `--strip-native-debug-symbols` seems reasonable but it will be > inconsistent with the existing `--strip-debug` option. Mandy - what you > would think about renaming the existing option to something that makes > it clear that it strips the debug attribute from class files? (we would > of course need to do something to keep the existing option working). Renaming it to make it clear is good. How about: --strip-debug-attribute --strip-native-debug-symbols --strip-debug will invoke both --strip-debug-attribute and --strip-native-debug-symbols, if supported. Typically we want to strip both. If only stripping debug attribute, then it can use --strip-debug-attribute. What do you think? > The need to specify the argument as "defaults" or "options" is a bit > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin accepts an optional argument. On the other hand, pluginToMaps will put an empty map if hasArguments return false. The plugin processing code (PluginsHelper) is quite complicated that I can't quite tell without spending time. In any case I think a plugin should support optional arguments. > The plugin interface is not > exported/documented/supported so we have flexibility to change it. If we > do this then it should mean the usages reduce down to: > > --strip-native-debug-symbols > --strip-native-debug-symbols objcopy=:... objcopy is fine. It would also be nice to allow `keep-debuginfo` taking an optional file extension. --strip-native-debug-symbols keep-debuginfo --strip-native-debug-symbols keep-debuginfo=dbg > > I see the plugin has moved to src/jdk.jlink/unix in this iteration. It > might be better to start out in src/jdk.jlink/linux - we can always move > to the unix tree in the event that there is interest/support on other > platforms. Agree. > Mandy points out the issue with wrapping in the usage output. I agree > that the`jlink --list-plugins` needs to be readable/tidy esp. in this > case as there are many sub-options to read about. I file JDK-8218685 for --list-plugins tidy up. Mandy From Alan.Bateman at oracle.com Sun Feb 10 15:33:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Feb 2019 15:33:02 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <5d2f03ff-1d64-bb9a-3c23-90274cbe6dec@oracle.com> On 08/02/2019 18:53, Mandy Chung wrote: > > Renaming it to make it clear is good.? How about: > > --strip-debug-attribute > --strip-native-debug-symbols > > --strip-debug will invoke both --strip-debug-attribute and > --strip-native-debug-symbols, if supported. > > Typically we want to strip both.? If only stripping debug attribute, > then it can use --strip-debug-attribute. > > What do you think? This make sense and I'm just wondering if we need to extend this to debug symbols that are in external files. This suggests exploring whether it should imply --exclude-files too. > : > > Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin > accepts an optional argument. I don't think --dedup-legal-notices works without an option. It would be generally useful to allow optional values. -Alan From sgehwolf at redhat.com Mon Feb 11 18:03:28 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Feb 2019 19:03:28 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> Message-ID: <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> Hi Erik, On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > On 2019-02-07 11:09, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > There is a macro for automatically finding all source dirs for a module. > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > that macro, like this: > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > The above could/should even be inlined. > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > from make/common/Modules.gmk which isn't included in > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > reluctant to include it here too. Without the new include the above > > won't work. > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > which is part of where Modules.gmk gets bootstrapped. In any normal > makefile (as in where stuff is just being built), the bootstrapping is > done and including Modules.gmk is completely fine. Any > -.gmk file certainly qualifies here. OK. Updated: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ Thanks, Severin > /Erik > > > Thanks, > > Severin > > > > > Otherwise build changes look ok. > > > > > > /Erik > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > debug > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > platforms. It's > > > > the first platform specific jlink plugin and the approach taken > > > > for > > > > keeping it contained is to use a plugin specific > > > > ResourceBundle. > > > > Discussion for this happened in [1]. > > > > > > > > The test uses a native library which should never get debug > > > > symbols > > > > stripped during the test library build. As such, tiny > > > > modifications > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > build-dev > > > > being on the list for this RFR. The test currently only runs on > > > > Linux > > > > and requires objcopy to be available. Otherwise the test is > > > > being > > > > skipped. > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > Linux > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > It's > > > > currently running through jdk/submit too. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > From sgehwolf at redhat.com Mon Feb 11 18:10:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Feb 2019 19:10:49 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: <3e804780fbf51164f1136c080a7091889b3b8343.camel@redhat.com> Hi Alan, Thanks for the review! On Fri, 2019-02-08 at 10:08 +0000, Alan Bateman wrote: > On 07/02/2019 17:09, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this enhancement? It adds a debug > > symbols stripping plug-in to jlink for Linux and Unix platforms. It's > > the first platform specific jlink plugin and the approach taken for > > keeping it contained is to use a plugin specific ResourceBundle. > > Discussion for this happened in [1]. > > > > The test uses a native library which should never get debug symbols > > stripped during the test library build. As such, tiny modifications > > were needed to make/common/TestFilesCompilation.gmk. Hence, build-dev > > being on the list for this RFR. The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > > > Example usage of this plugin is described in the bug. > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > I agree with Mandy that the CLI options need examination. The proposed > `--strip-native-debug-symbols` seems reasonable but it will be > inconsistent with the existing `--strip-debug` option. Mandy - what you > would think about renaming the existing option to something that makes > it clear that it strips the debug attribute from class files? (we would > of course need to do something to keep the existing option working). > > The need to specify the argument as "defaults" or "options" is a bit > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. The plugin interface is not > exported/documented/supported so we have flexibility to change it. I've filed this bug for optional arguments: https://bugs.openjdk.java.net/browse/JDK-8218761 It's a separate issue, after all. > If we > do this then it should mean the usages reduce down to: > > --strip-native-debug-symbols > --strip-native-debug-symbols objcopy=:... > > I see the plugin has moved to src/jdk.jlink/unix in this iteration. It > might be better to start out in src/jdk.jlink/linux - we can always move > to the unix tree in the event that there is interest/support on other > platforms. > > Mandy points out the issue with wrapping in the usage output. I agree > that the`jlink --list-plugins` needs to be readable/tidy esp. in this > case as there are many sub-options to read about. I'll tackle those once there is some agreement as to what the option should be called and which arguments it should have for the initial implementation. I'll reply with a proposal in the other thread. > The implementation will need a bit of a tidy up too. The readFileBytes > method can be replaced with Files.readAllBytes. The BAIS usage can be > replaced with Files.write. Ignoring exceptions thrown in stripBinary > will also need consideration. Should be fixed in the latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ FWIW, I've refrained from using Files.readAllBytes in the initial webrev because of this note in the javadoc: """ Note that this method is intended for simple cases where it is convenient to read all bytes into a byte array. It is not intended for reading in large files. """ Cheers, Severin From erik.joelsson at oracle.com Mon Feb 11 19:12:24 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2019 11:12:24 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> Message-ID: <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Hello Severin, I think you also need a $(wildcard ) around it, but I may be wrong. Did you try this version? Also, please do not indent so much. We have style guidelines [1], which recommend 4 spaces for line break indentation. /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2019-02-11 10:03, Severin Gehwolf wrote: > Hi Erik, > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >> On 2019-02-07 11:09, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>> Hello Severin, >>>> >>>> There is a macro for automatically finding all source dirs for a module. >>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>> that macro, like this: >>>> >>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>> >>>> The above could/should even be inlined. >>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>> from make/common/Modules.gmk which isn't included in >>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>> reluctant to include it here too. Without the new include the above >>> won't work. >>> >>> The approach I've taken here seems to be the lesser evil. Thoughts? >> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >> which is part of where Modules.gmk gets bootstrapped. In any normal >> makefile (as in where stuff is just being built), the bootstrapping is >> done and including Modules.gmk is completely fine. Any >> -.gmk file certainly qualifies here. > OK. Updated: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > Thanks, > Severin > >> /Erik >> >>> Thanks, >>> Severin >>> >>>> Otherwise build changes look ok. >>>> >>>> /Erik >>>> >>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could I please get reviews for this enhancement? It adds a >>>>> debug >>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>> platforms. It's >>>>> the first platform specific jlink plugin and the approach taken >>>>> for >>>>> keeping it contained is to use a plugin specific >>>>> ResourceBundle. >>>>> Discussion for this happened in [1]. >>>>> >>>>> The test uses a native library which should never get debug >>>>> symbols >>>>> stripped during the test library build. As such, tiny >>>>> modifications >>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>> build-dev >>>>> being on the list for this RFR. The test currently only runs on >>>>> Linux >>>>> and requires objcopy to be available. Otherwise the test is >>>>> being >>>>> skipped. >>>>> >>>>> Example usage of this plugin is described in the bug. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>> >>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>> Linux >>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>> It's >>>>> currently running through jdk/submit too. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>> From oliver.zemann at gmail.com Mon Feb 11 21:46:04 2019 From: oliver.zemann at gmail.com (Oliver Z.) Date: Mon, 11 Feb 2019 22:46:04 +0100 Subject: Problem with JAXBContext.newInstance Message-ID: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> Hi, i am trying to create a java 11 application which reads some .xml and that should be mapped to a object. Unfortunately, with java 11 this seems impossible. I created a stackoverflow posting. Maybe someone could take a look at that and help me with my problem. https://stackoverflow.com/questions/54632086/java-11-implementation-of-jaxb-api-has-not-been-found-on-module-path-or-classpa From lance.andersen at oracle.com Mon Feb 11 23:33:27 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Feb 2019 18:33:27 -0500 Subject: Problem with JAXBContext.newInstance In-Reply-To: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> Message-ID: Using the JAX-B standalone,https://github.com/eclipse-ee4j/jaxb-ri, seems a bit harder than it probably should be given where we are. The following command line with the jars on the classpath: ?????? java -cp classes/:jars/jaxb-api-2.4.0.jar:jars/jaxb-runtime-2.4.0.jar:jars/jaxb-impl-2.4.0.jar:jars/istack-commons-runtime-3.0.7.jar:jars/javax.activation-api-1.2.0.jar JAXBExample ????????? will work with the following trivial example: ??????? import javax.xml.bind.annotation.XmlAttribute; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Customer { String name; int age; int id; public String getName() { return name; } @XmlElement public void setName(String name) { this.name = name; } public int getAge() { return age; } @XmlElement public void setAge(int age) { this.age = age; } public int getId() { return id; } @XmlAttribute public void setId(int id) { this.id = id; } } import java.io.File; import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBException; import javax.xml.bind.Marshaller; public class JAXBExample { public static void main(String[] args) { Customer customer = new Customer(); customer.setId(100); customer.setName("Lance Andersen"); customer.setAge(29); try { File file = new File("Customer.xml"); JAXBContext jaxbContext = JAXBContext.newInstance(Customer.class); Marshaller jaxbMarshaller = jaxbContext.createMarshaller(); // output pretty printed jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); jaxbMarshaller.marshal(customer, file); jaxbMarshaller.marshal(customer, System.out); } catch (JAXBException e) { e.printStackTrace(); } } } ?????????? The JAX-B 2.4 documentation could be a bit more helpful https://javaee.github.io/jaxb-v2/doc/user-guide/release-documentation.html#deployment-jaxb-on-jpms :-( HTH Lance > On Feb 11, 2019, at 4:46 PM, Oliver Z. wrote: > > Hi, i am trying to create a java 11 application which reads some .xml and that should be mapped to a object. Unfortunately, with java 11 this seems impossible. I created a stackoverflow posting. Maybe someone could take a look at that and help me with my problem. https://stackoverflow.com/questions/54632086/java-11-implementation-of-jaxb-api-has-not-been-found-on-module-path-or-classpa > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From oliver.zemann at gmail.com Tue Feb 12 00:03:29 2019 From: oliver.zemann at gmail.com (Oliver Z.) Date: Tue, 12 Feb 2019 01:03:29 +0100 Subject: Problem with JAXBContext.newInstance In-Reply-To: References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> Message-ID: <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> Thanks for the documentation link. It says, JPMS is supported when jaxb 2.4.0 comes out. So in that case, this is simply not yet supported, is this correct? For the moment, i can remove the module-info.java, then it works - at least for the moment as workaround, until 2.4.0 is released. I believe, the example below only works because it has no module-info.java > Using the JAX-B standalone,https://github.com/eclipse-ee4j/jaxb-ri, > seems a bit harder than it probably should be given where we are. > > The following command line ?with the jars on the classpath: > ?????? > java -cp > classes/:jars/jaxb-api-2.4.0.jar:jars/jaxb-runtime-2.4.0.jar:jars/jaxb-impl-2.4.0.jar:jars/istack-commons-runtime-3.0.7.jar:jars/javax.activation-api-1.2.0.jar > JAXBExample > ????????? > > will work with the following trivial example: > > ??????? > import javax.xml.bind.annotation.XmlAttribute; > import javax.xml.bind.annotation.XmlElement; > import javax.xml.bind.annotation.XmlRootElement; > > @XmlRootElement > public class Customer { > > ? ? String name; > ? ? int age; > ? ? int id; > > ? ? public String getName() { > ? ? ? ? return name; > ? ? } > > ? ? @XmlElement > ? ? public void setName(String name) { > ? ? ? ? this.name = name; > ? ? } > > ? ? public int getAge() { > ? ? ? ? return age; > ? ? } > > ? ? @XmlElement > ? ? public void setAge(int age) { > ? ? ? ? this.age = age; > ? ? } > > ? ? public int getId() { > ? ? ? ? return id; > ? ? } > > ? ? @XmlAttribute > ? ? public void setId(int id) { > ? ? ? ? this.id = id; > ? ? } > > } > > import java.io.File; > import javax.xml.bind.JAXBContext; > import javax.xml.bind.JAXBException; > import javax.xml.bind.Marshaller; > > public class JAXBExample { > ? ? public static void main(String[] args) { > > ? ? ? ? Customer customer = new Customer(); > ? ? ? ? customer.setId(100); > customer.setName("Lance Andersen"); > ? ? ? ? customer.setAge(29); > > ? ? ? ? try { > > ? ? ? ? ? ? File file = new File("Customer.xml"); > ? ? ? ? ? ? JAXBContext jaxbContext = > JAXBContext.newInstance(Customer.class); > ? ? ? ? ? ? Marshaller jaxbMarshaller = jaxbContext.createMarshaller(); > > ? ? ? ? ? ? // output pretty printed > jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); > > jaxbMarshaller.marshal(customer, file); > jaxbMarshaller.marshal(customer, System.out); > > ? ? ? ? } catch (JAXBException e) { > e.printStackTrace(); > ? ? ? ? } > > ? ? } > } > ?????????? > > The JAX-B 2.4 documentation could be a bit more helpful > https://javaee.github.io/jaxb-v2/doc/user-guide/release-documentation.html#deployment-jaxb-on-jpms?:-( > > > HTH > > Lance > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Tue Feb 12 00:28:48 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Feb 2019 19:28:48 -0500 Subject: Problem with JAXBContext.newInstance In-Reply-To: <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> Message-ID: The last time I tried, you could not use JAXB 2.4 as a module but that was before it went final. JAXB has dependencies on JAF so make sure you include that module. If you are still struggling I would follow up on the JAXB dev mailing list https://javaee.groups.io/g/metro for better guidance with JAXB 2.4 The documentation definitely needs some updates to 7.2.2 as it does not even mention JAF or provide a current of example for using the standalone JAXB as a module without upgrading the JDK implementation. Also the release notes do not mention the runtime jar https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html#jars > On Feb 11, 2019, at 7:03 PM, Oliver Z. wrote: > > Thanks for the documentation link. It says, JPMS is supported when jaxb 2.4.0 comes out. So in that case, this is simply not yet supported, is this correct? For the moment, i can remove the module-info.java, then it works - at least for the moment as workaround, until 2.4.0 is released. > I believe, the example below only works because it has no module-info.java > >> Using the JAX-B standalone,https://github.com/eclipse-ee4j/jaxb-ri , seems a bit harder than it probably should be given where we are. >> >> The following command line with the jars on the classpath: >> ?????? >> java -cp classes/:jars/jaxb-api-2.4.0.jar:jars/jaxb-runtime-2.4.0.jar:jars/jaxb-impl-2.4.0.jar:jars/istack-commons-runtime-3.0.7.jar:jars/javax.activation-api-1.2.0.jar JAXBExample >> ????????? >> >> will work with the following trivial example: >> >> ??????? >> import javax.xml.bind.annotation.XmlAttribute; >> import javax.xml.bind.annotation.XmlElement; >> import javax.xml.bind.annotation.XmlRootElement; >> >> @XmlRootElement >> public class Customer { >> >> String name; >> int age; >> int id; >> >> public String getName() { >> return name; >> } >> >> @XmlElement >> public void setName(String name) { >> this.name = name; >> } >> >> public int getAge() { >> return age; >> } >> >> @XmlElement >> public void setAge(int age) { >> this.age = age; >> } >> >> public int getId() { >> return id; >> } >> >> @XmlAttribute >> public void setId(int id) { >> this.id = id; >> } >> >> } >> >> import java.io.File; >> import javax.xml.bind.JAXBContext; >> import javax.xml.bind.JAXBException; >> import javax.xml.bind.Marshaller; >> >> public class JAXBExample { >> public static void main(String[] args) { >> >> Customer customer = new Customer(); >> customer.setId(100); >> customer.setName("Lance Andersen"); >> customer.setAge(29); >> >> try { >> >> File file = new File("Customer.xml"); >> JAXBContext jaxbContext = JAXBContext.newInstance(Customer.class); >> Marshaller jaxbMarshaller = jaxbContext.createMarshaller(); >> >> // output pretty printed >> jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); >> >> jaxbMarshaller.marshal(customer, file); >> jaxbMarshaller.marshal(customer, System.out); >> >> } catch (JAXBException e) { >> e.printStackTrace(); >> } >> >> } >> } >> ?????????? >> >> The JAX-B 2.4 documentation could be a bit more helpful https://javaee.github.io/jaxb-v2/doc/user-guide/release-documentation.html#deployment-jaxb-on-jpms :-( >> >> >> HTH >> >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From sgehwolf at redhat.com Tue Feb 12 09:35:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 10:35:09 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: Hi Erik, On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: > Hello Severin, > > I think you also need a $(wildcard ) around it, but I may be wrong. Did > you try this version? Yes, this version works for me without $(wildcard). Why is it needed? > Also, please do not indent so much. We have style guidelines [1], which > recommend 4 spaces for line break indentation. OK, sorry. Fixed locally. Thanks, Severin > /Erik > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > On 2019-02-11 10:03, Severin Gehwolf wrote: > > Hi Erik, > > > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > > > On 2019-02-07 11:09, Severin Gehwolf wrote: > > > > Hi Erik, > > > > > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > > > Hello Severin, > > > > > > > > > > There is a macro for automatically finding all source dirs for a module. > > > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > > > that macro, like this: > > > > > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > > > > > The above could/should even be inlined. > > > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > > > from make/common/Modules.gmk which isn't included in > > > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > > > reluctant to include it here too. Without the new include the above > > > > won't work. > > > > > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > > > which is part of where Modules.gmk gets bootstrapped. In any normal > > > makefile (as in where stuff is just being built), the bootstrapping is > > > done and including Modules.gmk is completely fine. Any > > > -.gmk file certainly qualifies here. > > OK. Updated: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > > > Thanks, > > Severin > > > > > /Erik > > > > > > > Thanks, > > > > Severin > > > > > > > > > Otherwise build changes look ok. > > > > > > > > > > /Erik > > > > > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > > > debug > > > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > > > platforms. It's > > > > > > the first platform specific jlink plugin and the approach taken > > > > > > for > > > > > > keeping it contained is to use a plugin specific > > > > > > ResourceBundle. > > > > > > Discussion for this happened in [1]. > > > > > > > > > > > > The test uses a native library which should never get debug > > > > > > symbols > > > > > > stripped during the test library build. As such, tiny > > > > > > modifications > > > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > > > build-dev > > > > > > being on the list for this RFR. The test currently only runs on > > > > > > Linux > > > > > > and requires objcopy to be available. Otherwise the test is > > > > > > being > > > > > > skipped. > > > > > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > > > > > webrev: > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > > > Linux > > > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > > > It's > > > > > > currently running through jdk/submit too. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] > > > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > > > From erik.joelsson at oracle.com Tue Feb 12 16:44:48 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2019 08:44:48 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: On 2019-02-12 01:35, Severin Gehwolf wrote: > Hi Erik, > > On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: >> Hello Severin, >> >> I think you also need a $(wildcard ) around it, but I may be wrong. Did >> you try this version? > Yes, this version works for me without $(wildcard). Why is it needed? I had to go back and check again to verify, but now I'm sure. The list of directories returned by FindModuleSrcDirs is all src dirs for the module. Not all of them are going to contain the specific directory jdk/tools/jlink/resources. This means SetupCompileProperties will get called with a few non existing directories. While this will work fine, the find implementation on some platforms will complain (Macos in particular), so to avoid introducing confusing warning messages in the build, it's better to filter down the list of directories to those that actually exist. >> Also, please do not indent so much. We have style guidelines [1], which >> recommend 4 spaces for line break indentation. > OK, sorry. Fixed locally. Thanks! /Erik > Thanks, > Severin > >> /Erik >> >> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> On 2019-02-11 10:03, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >>>> On 2019-02-07 11:09, Severin Gehwolf wrote: >>>>> Hi Erik, >>>>> >>>>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>>>> Hello Severin, >>>>>> >>>>>> There is a macro for automatically finding all source dirs for a module. >>>>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>>>> that macro, like this: >>>>>> >>>>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>>>> >>>>>> The above could/should even be inlined. >>>>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>>>> from make/common/Modules.gmk which isn't included in >>>>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>>>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>>>> reluctant to include it here too. Without the new include the above >>>>> won't work. >>>>> >>>>> The approach I've taken here seems to be the lesser evil. Thoughts? >>>> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >>>> which is part of where Modules.gmk gets bootstrapped. In any normal >>>> makefile (as in where stuff is just being built), the bootstrapping is >>>> done and including Modules.gmk is completely fine. Any >>>> -.gmk file certainly qualifies here. >>> OK. Updated: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ >>> >>> Thanks, >>> Severin >>> >>>> /Erik >>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> Otherwise build changes look ok. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this enhancement? It adds a >>>>>>> debug >>>>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>>>> platforms. It's >>>>>>> the first platform specific jlink plugin and the approach taken >>>>>>> for >>>>>>> keeping it contained is to use a plugin specific >>>>>>> ResourceBundle. >>>>>>> Discussion for this happened in [1]. >>>>>>> >>>>>>> The test uses a native library which should never get debug >>>>>>> symbols >>>>>>> stripped during the test library build. As such, tiny >>>>>>> modifications >>>>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>>>> build-dev >>>>>>> being on the list for this RFR. The test currently only runs on >>>>>>> Linux >>>>>>> and requires objcopy to be available. Otherwise the test is >>>>>>> being >>>>>>> skipped. >>>>>>> >>>>>>> Example usage of this plugin is described in the bug. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>>>> >>>>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>>>> Linux >>>>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>>>> It's >>>>>>> currently running through jdk/submit too. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>>>> From sgehwolf at redhat.com Tue Feb 12 17:05:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 18:05:48 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> Message-ID: <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> Hi Erik, On Tue, 2019-02-12 at 08:44 -0800, Erik Joelsson wrote: > On 2019-02-12 01:35, Severin Gehwolf wrote: > > Hi Erik, > > > > On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: > > > Hello Severin, > > > > > > I think you also need a $(wildcard ) around it, but I may be wrong. Did > > > you try this version? > > Yes, this version works for me without $(wildcard). Why is it needed? > > I had to go back and check again to verify, but now I'm sure. The list > of directories returned by FindModuleSrcDirs is all src dirs for the > module. Not all of them are going to contain the specific directory > jdk/tools/jlink/resources. This means SetupCompileProperties will get > called with a few non existing directories. While this will work fine, > the find implementation on some platforms will complain (Macos in > particular), so to avoid introducing confusing warning messages in the > build, it's better to filter down the list of directories to those that > actually exist. OK, thanks for the explanation. I suppose $(wildcard ...) does that, then? I've added it back locally but I have no way of testing whether this makes any difference, except jdk/submit perhaps? diff --git a/make/gensrc/Gensrc-jdk.jlink.gmk b/make/gensrc/Gensrc-jdk.jlink.gmk --- a/make/gensrc/Gensrc-jdk.jlink.gmk +++ b/make/gensrc/Gensrc-jdk.jlink.gmk @@ -29,8 +29,9 @@ ################################################################################ -JLINK_RESOURCES_DIRS := $(addsuffix /jdk/tools/jlink/resources, \ - $(call FindModuleSrcDirs, jdk.jlink)) +# Use wildcard so as to avoid getting non-existing directories back +JLINK_RESOURCES_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, \ + $(call FindModuleSrcDirs, jdk.jlink))) $(eval $(call SetupCompileProperties, JLINK_PROPERTIES, \ SRC_DIRS := $(JLINK_RESOURCES_DIRS), \ Thanks, Severin > > > Also, please do not indent so much. We have style guidelines [1], which > > > recommend 4 spaces for line break indentation. > > OK, sorry. Fixed locally. > > Thanks! > > /Erik > > > Thanks, > > Severin > > > > > /Erik > > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html > > > > > > On 2019-02-11 10:03, Severin Gehwolf wrote: > > > > Hi Erik, > > > > > > > > On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: > > > > > On 2019-02-07 11:09, Severin Gehwolf wrote: > > > > > > Hi Erik, > > > > > > > > > > > > On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: > > > > > > > Hello Severin, > > > > > > > > > > > > > > There is a macro for automatically finding all source dirs for a module. > > > > > > > So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using > > > > > > > that macro, like this: > > > > > > > > > > > > > > JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix > > > > > > > /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) > > > > > > > > > > > > > > The above could/should even be inlined. > > > > > > I've considered this. It seems, though, that FindModuleSrcDirs comes > > > > > > from make/common/Modules.gmk which isn't included in > > > > > > make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused > > > > > > problems with multiple includes of Modules.gmk (JDK-8213736) I was > > > > > > reluctant to include it here too. Without the new include the above > > > > > > won't work. > > > > > > > > > > > > The approach I've taken here seems to be the lesser evil. Thoughts? > > > > > I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, > > > > > which is part of where Modules.gmk gets bootstrapped. In any normal > > > > > makefile (as in where stuff is just being built), the bootstrapping is > > > > > done and including Modules.gmk is completely fine. Any > > > > > -.gmk file certainly qualifies here. > > > > OK. Updated: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > /Erik > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > Otherwise build changes look ok. > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > On 2019-02-07 09:09, Severin Gehwolf wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could I please get reviews for this enhancement? It adds a > > > > > > > > debug > > > > > > > > symbols stripping plug-in to jlink for Linux and Unix > > > > > > > > platforms. It's > > > > > > > > the first platform specific jlink plugin and the approach taken > > > > > > > > for > > > > > > > > keeping it contained is to use a plugin specific > > > > > > > > ResourceBundle. > > > > > > > > Discussion for this happened in [1]. > > > > > > > > > > > > > > > > The test uses a native library which should never get debug > > > > > > > > symbols > > > > > > > > stripped during the test library build. As such, tiny > > > > > > > > modifications > > > > > > > > were needed to make/common/TestFilesCompilation.gmk. Hence, > > > > > > > > build-dev > > > > > > > > being on the list for this RFR. The test currently only runs on > > > > > > > > Linux > > > > > > > > and requires objcopy to be available. Otherwise the test is > > > > > > > > being > > > > > > > > skipped. > > > > > > > > > > > > > > > > Example usage of this plugin is described in the bug. > > > > > > > > > > > > > > > > webrev: > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 > > > > > > > > > > > > > > > > Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on > > > > > > > > Linux > > > > > > > > x86_64 (with good and broken objcopy) and the newly added test. > > > > > > > > It's > > > > > > > > currently running through jdk/submit too. > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Severin > > > > > > > > > > > > > > > > [1] > > > > > > > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html > > > > > > > > From erik.joelsson at oracle.com Tue Feb 12 17:10:23 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Feb 2019 09:10:23 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6b2c8424-4091-08ec-59e8-f1ee02b0b28d@oracle.com> <2bc99398-4557-2d5c-0ee4-5615bea2c49c@oracle.com> <7335aff6d4337a21cbf4ccabc00d6d7ac2eb45aa.camel@redhat.com> <6c2a0ef5-2c2d-a7f3-096c-a8cca8487b77@oracle.com> <10369b87099fa48f796161ac5bc1cb08dc6f5cc5.camel@redhat.com> Message-ID: <17f599cc-22d8-6dd2-e187-b8e03da4eda3@oracle.com> Hello, On 2019-02-12 09:05, Severin Gehwolf wrote: > Hi Erik, > > On Tue, 2019-02-12 at 08:44 -0800, Erik Joelsson wrote: >> On 2019-02-12 01:35, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Mon, 2019-02-11 at 11:12 -0800, Erik Joelsson wrote: >>>> Hello Severin, >>>> >>>> I think you also need a $(wildcard ) around it, but I may be wrong. Did >>>> you try this version? >>> Yes, this version works for me without $(wildcard). Why is it needed? >> I had to go back and check again to verify, but now I'm sure. The list >> of directories returned by FindModuleSrcDirs is all src dirs for the >> module. Not all of them are going to contain the specific directory >> jdk/tools/jlink/resources. This means SetupCompileProperties will get >> called with a few non existing directories. While this will work fine, >> the find implementation on some platforms will complain (Macos in >> particular), so to avoid introducing confusing warning messages in the >> build, it's better to filter down the list of directories to those that >> actually exist. > OK, thanks for the explanation. I suppose $(wildcard ...) does that, > then? I've added it back locally but I have no way of testing whether > this makes any difference, except jdk/submit perhaps? Yes, that is what wildcard does, it filters out any non existing dirs. No need for you to verify anything but that it works as far as I am concerned. I'm happy with the below. /Erik > diff --git a/make/gensrc/Gensrc-jdk.jlink.gmk b/make/gensrc/Gensrc-jdk.jlink.gmk > --- a/make/gensrc/Gensrc-jdk.jlink.gmk > +++ b/make/gensrc/Gensrc-jdk.jlink.gmk > @@ -29,8 +29,9 @@ > > ################################################################################ > > -JLINK_RESOURCES_DIRS := $(addsuffix /jdk/tools/jlink/resources, \ > - $(call FindModuleSrcDirs, jdk.jlink)) > +# Use wildcard so as to avoid getting non-existing directories back > +JLINK_RESOURCES_DIRS := $(wildcard $(addsuffix /jdk/tools/jlink/resources, \ > + $(call FindModuleSrcDirs, jdk.jlink))) > > $(eval $(call SetupCompileProperties, JLINK_PROPERTIES, \ > SRC_DIRS := $(JLINK_RESOURCES_DIRS), \ > > Thanks, > Severin > >>>> Also, please do not indent so much. We have style guidelines [1], which >>>> recommend 4 spaces for line break indentation. >>> OK, sorry. Fixed locally. >> Thanks! >> >> /Erik >> >>> Thanks, >>> Severin >>> >>>> /Erik >>>> >>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html >>>> >>>> On 2019-02-11 10:03, Severin Gehwolf wrote: >>>>> Hi Erik, >>>>> >>>>> On Thu, 2019-02-07 at 17:01 -0800, Erik Joelsson wrote: >>>>>> On 2019-02-07 11:09, Severin Gehwolf wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On Thu, 2019-02-07 at 09:39 -0800, Erik Joelsson wrote: >>>>>>>> Hello Severin, >>>>>>>> >>>>>>>> There is a macro for automatically finding all source dirs for a module. >>>>>>>> So in Gensrc-jdk.jlink.gmk, I think it would be better expressed using >>>>>>>> that macro, like this: >>>>>>>> >>>>>>>> JLINK_RESOURCE_DIRS := $(wildcard $(addsuffix >>>>>>>> /jdk/tools/jlink/resources, $(call FindModuleSrcSdirs, jdk.jlink))) >>>>>>>> >>>>>>>> The above could/should even be inlined. >>>>>>> I've considered this. It seems, though, that FindModuleSrcDirs comes >>>>>>> from make/common/Modules.gmk which isn't included in >>>>>>> make/gensrc/Gensrc-jdk.jlink.gmk. Given that it has already caused >>>>>>> problems with multiple includes of Modules.gmk (JDK-8213736) I was >>>>>>> reluctant to include it here too. Without the new include the above >>>>>>> won't work. >>>>>>> >>>>>>> The approach I've taken here seems to be the lesser evil. Thoughts? >>>>>> I appreciate your concern, but JDK-8213736 was a problem in Main.gmk, >>>>>> which is part of where Modules.gmk gets bootstrapped. In any normal >>>>>> makefile (as in where stuff is just being built), the bootstrapping is >>>>>> done and including Modules.gmk is completely fine. Any >>>>>> -.gmk file certainly qualifies here. >>>>> OK. Updated: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> /Erik >>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>>>>>>> Otherwise build changes look ok. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2019-02-07 09:09, Severin Gehwolf wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could I please get reviews for this enhancement? It adds a >>>>>>>>> debug >>>>>>>>> symbols stripping plug-in to jlink for Linux and Unix >>>>>>>>> platforms. It's >>>>>>>>> the first platform specific jlink plugin and the approach taken >>>>>>>>> for >>>>>>>>> keeping it contained is to use a plugin specific >>>>>>>>> ResourceBundle. >>>>>>>>> Discussion for this happened in [1]. >>>>>>>>> >>>>>>>>> The test uses a native library which should never get debug >>>>>>>>> symbols >>>>>>>>> stripped during the test library build. As such, tiny >>>>>>>>> modifications >>>>>>>>> were needed to make/common/TestFilesCompilation.gmk. Hence, >>>>>>>>> build-dev >>>>>>>>> being on the list for this RFR. The test currently only runs on >>>>>>>>> Linux >>>>>>>>> and requires objcopy to be available. Otherwise the test is >>>>>>>>> being >>>>>>>>> skipped. >>>>>>>>> >>>>>>>>> Example usage of this plugin is described in the bug. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214796 >>>>>>>>> >>>>>>>>> Testing: test/jdk/tools/jlink test/jdk/jdk/modules tests on >>>>>>>>> Linux >>>>>>>>> x86_64 (with good and broken objcopy) and the newly added test. >>>>>>>>> It's >>>>>>>>> currently running through jdk/submit too. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Severin >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014109.html >>>>>>>>> From sgehwolf at redhat.com Tue Feb 12 19:52:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 20:52:36 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: Hi Mandy, Alan, Please find the proposal for CLI option of --strip-native-debug-symbols below. On Fri, 2019-02-08 at 10:53 -0800, Mandy Chung wrote: > > On 2/8/19 2:08 AM, Alan Bateman wrote: > > I agree with Mandy that the CLI options need examination. The proposed > > `--strip-native-debug-symbols` seems reasonable but it will be > > inconsistent with the existing `--strip-debug` option. Mandy - what you > > would think about renaming the existing option to something that makes > > it clear that it strips the debug attribute from class files? (we would > > of course need to do something to keep the existing option working). > > Renaming it to make it clear is good. How about: > > --strip-debug-attribute > --strip-native-debug-symbols > > --strip-debug will invoke both --strip-debug-attribute and > --strip-native-debug-symbols, if supported. > > Typically we want to strip both. If only stripping debug attribute, > then it can use --strip-debug-attribute. > > What do you think? > > > The need to specify the argument as "defaults" or "options" is a bit > > annoying. It might be time to replace hasArguments in the plugin > interface to allow for optional arguments. > > Hmm... I thought it allows optional arguments. LegalNoticeFilePlugin > accepts an optional argument. > > On the other hand, pluginToMaps will put an empty map if hasArguments > return false. The plugin processing code (PluginsHelper) is quite > complicated that I can't quite tell without spending time. > > In any case I think a plugin should support optional arguments. > > > The plugin interface is not > > exported/documented/supported so we have flexibility to change it. If we > > do this then it should mean the usages reduce down to: > > > > --strip-native-debug-symbols > > --strip-native-debug-symbols objcopy=:... > > objcopy is fine. > > It would also be nice to allow `keep-debuginfo` taking an optional > file extension. > > --strip-native-debug-symbols keep-debuginfo > --strip-native-debug-symbols keep-debuginfo=dbg The current implementation here has the following options: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ [i] --strip-native-debug-symbols defaults [ii] --strip-native-debug-symbols options:objcopy-cmd= [iii] --strip-native-debug-symbols options:debuginfo-file-ext= [iv] --strip-native-debug-symbols options:include-debug-syms=true The first option is a work-around for JDK-8218761. AFAIUI, fixing it will need rework of the Plugin interface and probably of the options parsing. Hence, I'd like to defer this post integration of the initial version of --strip-native-debug-symbols plugin. Cases [iii] and [iv] can be folded into one as suggested by Mandy with: --strip-native-debug-symbols keep-debuginfo --strip-native-debug-symbols keep-debuginfo= Case [ii] would become: --strip-native-debug-symbols objcopy= So in summary I'd propose these, where a) and b) may be combined, c) and a) or c) and b) combined would be an error: [a] --strip-native-debug-symbols keep-debuginfo[=] [b] --strip-native-debug-symbols objcopy= [c] --strip-native-debug-symbols defaults As a follow-up to an initial implementation of the above, I'd propose to hook it up with the current --strip-debug by a follow-up patch. It would first rename --strip-debug to --strip-debug-attribute or perhaps --strip-java-debug-symbols, and then let --strip-debug perform java and native debug symbols stripping as Alan suggested. Does that sound reasonable to you? Thanks, Severin From sgehwolf at redhat.com Tue Feb 12 20:05:55 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Feb 2019 21:05:55 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: Hi Mandy, Thanks for the review! On Thu, 2019-02-07 at 12:43 -0800, Mandy Chung wrote: > Hi Severin, > > Using the plugin specific ResourceBundle is good. Thanks for making > the change. > > I see that Alan's comment [1] on the plugin options and I assume > you will investigate the plugin options and bring back a proposal. > Did I miss the discussion on these options? > > Option: > --strip-native-debug-symbols=][:debuginfo-file-ext=][:include-debug-syms=true]> > > Examples: --strip-native-debug-symbols=defaults > > I suggest the above be simplified and drop the "=defaults". Simply: > --strip-native-debug-symbols > > Examples: > --strip-native-debug-symbols=options:objcopy-cmd=/usr/bin/objcopy:debuginfo-file-ext=dbg:include-debug-syms=true > > > If include-debug-syms=true then it will run > objcopy --only-keep-debug foo foo. to create debug symbols file > objcopy --add-gnu-debuglink=foo.dbg foo > > So what about simplifying the options to: > > --strip-native-debug-symbols=keep-debug-symbols=dbg,objcopy-path=/usr/bin/objcopy > > We could also drop the word "symbols": > > > --strip-native-debug=[keep-debug=,][objcopy-path=] > > By default, `--strip-native-debug` will strip native debug symbols > and don't keep debug symbols. > > keep-debug= creates the debug symbols file. > specifies the file extension. It would be > nice to use the default `debuginfo` extension and simply > accept `keep-debug` option. > > `objcopy-cmd` may be okay too. Others may have opinion. > > I think we should agree on the plugin options first before > doing the code review. OK. Here is the summary: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html Personally, I find --strip-native-debug-info or --strip-native-debug- symbols clearer than just --strip-native-debug. > > W.r.t. the test: > > > The test currently only runs on Linux > > and requires objcopy to be available. Otherwise the test is being > > skipped. > > We can create a fake objcopy utility for testing purpose > such that the test will validate if the options are passed > properly to the test utility. AFAIK, objcopy is a build requirement for OpenJDK already, so I'm wondering whether it makes sense to stub objcopy for the tests. Perhaps you meant that to be used in addition to existing tests? Anyhow, I'll look into it. It'll likely have to use the '--strip- native-debug-symbols objcopy= > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ > > I haven't reviewed the new files. Just notice that very long > lines in the new files that you may want to fix the formatting > that will help further side-by-side review. Some of the longer lines have been cleaned up in the lates webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > The --list-plugin output is very very long. The existing plugins > didn't set a good example to keep the well formatted (I recorded > that they were cleaned up at one point to keep 80 chars width). Right. I'll make sure --list-plugins looks right for --strip-native- debug-symbols once we've agreed on the options. > One other question: should this plugin be moved to linux/classes > rather than unix/classes given that that's the platform it > intends to support? Done in version 05. Thanks, Severin > Mandy > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-January/014099.html From mandy.chung at oracle.com Tue Feb 12 22:27:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Feb 2019 14:27:20 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> Message-ID: On 2/12/19 12:05 PM, Severin Gehwolf wrote: > Hi Mandy, > > Thanks for the review! > > OK. Here is the summary: > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014132.html > > Personally, I find --strip-native-debug-info or --strip-native-debug- > symbols clearer than just --strip-native-debug. Fine with me and we can stick with --strip-native-debug-symbols >> W.r.t. the test: >> >> > The test currently only runs on Linux >> > and requires objcopy to be available. Otherwise the test is being >> > skipped. >> >> We can create a fake objcopy utility for testing purpose >> such that the test will validate if the options are passed >> properly to the test utility. > > AFAIK, objcopy is a build requirement for OpenJDK already, so I'm > wondering whether it makes sense to stub objcopy for the tests. Perhaps > you meant that to be used in addition to existing tests? Test machines may not have objcopy. It'd increase the test coverage to include a test that can run on all test machines. Yes it's an additional test in addition to a test you have that only runs if objcopy utility is present. > Anyhow, I'll look into it. It'll likely have to use the '--strip- > native-debug-symbols objcopy= case. What I was thinking is: --strip-native-debug-symbols objcopy="java fakeobjcopy" where objcopy accepts a command that can contain arguments. It'll have to be some native code which will require some custom > make machinery to get compiled, no? If you have pointers to examples in > the JDK already, I'd appreciate it. See the idea above. >> > webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/04/webrev/ >> >> I haven't reviewed the new files. Just notice that very long >> lines in the new files that you may want to fix the formatting >> that will help further side-by-side review. > > Some of the longer lines have been cleaned up in the lates webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > >> The --list-plugin output is very very long. The existing plugins >> didn't set a good example to keep the well formatted (I recorded >> that they were cleaned up at one point to keep 80 chars width). > > Right. I'll make sure --list-plugins looks right for --strip-native- > debug-symbols once we've agreed on the options. > >> One other question: should this plugin be moved to linux/classes >> rather than unix/classes given that that's the platform it >> intends to support? > > Done in version 05. Thanks for making the change. I will reply the other thread. Mandy From mandy.chung at oracle.com Tue Feb 12 23:29:28 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Feb 2019 15:29:28 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On 2/12/19 11:52 AM, Severin Gehwolf wrote: > Hi Mandy, Alan, > > Please find the proposal for CLI option of --strip-native-debug-symbols > below. > > The current implementation here has the following options: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > > [i] --strip-native-debug-symbols defaults > [ii] --strip-native-debug-symbols options:objcopy-cmd= > [iii] --strip-native-debug-symbols options:debuginfo-file-ext= > [iv] --strip-native-debug-symbols options:include-debug-syms=true > > The first option is a work-around for JDK-8218761. AFAIUI, fixing it > will need rework of the Plugin interface and probably of the options > parsing. Hence, I'd like to defer this post integration of the initial > version of --strip-native-debug-symbols plugin. > > Cases [iii] and [iv] can be folded into one as suggested by Mandy with: > > --strip-native-debug-symbols keep-debuginfo > --strip-native-debug-symbols keep-debuginfo= > > Case [ii] would become: > > --strip-native-debug-symbols objcopy= we could relax this to a command that can contain arguments. > So in summary I'd propose these, where a) and b) may be combined, c) > and a) or c) and b) combined would be an error: > > [a] --strip-native-debug-symbols keep-debuginfo[=] > [b] --strip-native-debug-symbols objcopy= > [c] --strip-native-debug-symbols defaults This is a good compromise. When JDK-8218761 is implemented, [c] can become `--strip-native-debug-symbols` "defaults" is unclear to what it does. What about --strip-native-debug-symbols no-keep-debuginfo > As a follow-up to an initial implementation of the above, I'd propose > to hook it up with the current --strip-debug by a follow-up patch. It > would first rename --strip-debug to --strip-debug-attribute or perhaps > --strip-java-debug-symbols, and then let --strip-debug perform java and > native debug symbols stripping as Alan suggested. The renaming can be done separately. I would prefer changing --strip-debug to invoke --strip-native-debug-symbols, if present, at the same time with this new strip native debug symbols plugin to ensure that they all go in the same release. In other words, the renaming should be done before this new plugin. That's my opinion. Mandy > Does that sound reasonable to you? > > Thanks, > Severin > From sgehwolf at redhat.com Wed Feb 13 09:04:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 Feb 2019 10:04:29 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On Tue, 2019-02-12 at 15:29 -0800, Mandy Chung wrote: > > On 2/12/19 11:52 AM, Severin Gehwolf wrote: > > Hi Mandy, Alan, > > > > Please find the proposal for CLI option of --strip-native-debug-symbols > > below. > > > > The current implementation here has the following options: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/05/webrev/ > > > > [i] --strip-native-debug-symbols defaults > > [ii] --strip-native-debug-symbols options:objcopy-cmd= > > [iii] --strip-native-debug-symbols options:debuginfo-file-ext= > > [iv] --strip-native-debug-symbols options:include-debug-syms=true > > > > The first option is a work-around for JDK-8218761. AFAIUI, fixing it > > will need rework of the Plugin interface and probably of the options > > parsing. Hence, I'd like to defer this post integration of the initial > > version of --strip-native-debug-symbols plugin. > > > > Cases [iii] and [iv] can be folded into one as suggested by Mandy with: > > > > --strip-native-debug-symbols keep-debuginfo > > --strip-native-debug-symbols keep-debuginfo= > > > > Case [ii] would become: > > > > --strip-native-debug-symbols objcopy= > > we could relax this to a command that can contain arguments. OK. I'll explore that. > > So in summary I'd propose these, where a) and b) may be combined, c) > > and a) or c) and b) combined would be an error: > > > > [a] --strip-native-debug-symbols keep-debuginfo[=] > > [b] --strip-native-debug-symbols objcopy= > > [c] --strip-native-debug-symbols defaults > > This is a good compromise. When JDK-8218761 is implemented, > [c] can become `--strip-native-debug-symbols` > > "defaults" is unclear to what it does. What about > --strip-native-debug-symbols no-keep-debuginfo Makes sense. How about this? --strip-native-debug-symbols strip-debuginfo or --strip-native-debug-symbols remove-debuginfo It would avoid using negation. > > As a follow-up to an initial implementation of the above, I'd propose > > to hook it up with the current --strip-debug by a follow-up patch. It > > would first rename --strip-debug to --strip-debug-attribute or perhaps > > --strip-java-debug-symbols, and then let --strip-debug perform java and > > native debug symbols stripping as Alan suggested. > > The renaming can be done separately. I would prefer changing > --strip-debug to invoke --strip-native-debug-symbols, if present, > at the same time with this new strip native debug symbols plugin > to ensure that they all go in the same release. > > In other words, the renaming should be done before this new plugin. > That's my opinion. Sure. I've filed JDK-8218913 for doing this first. Would a name of -- strip-java-debug-symbols be acceptable? My thinking is that it would have nice symmetry with --strip-native-debug-symbols. Thoughts? Thanks, Severin > Mandy > > > Does that sound reasonable to you? > > > > Thanks, > > Severin > > From oliver.zemann at gmail.com Wed Feb 13 11:14:07 2019 From: oliver.zemann at gmail.com (Oliver Z.) Date: Wed, 13 Feb 2019 12:14:07 +0100 Subject: Problem with JAXBContext.newInstance In-Reply-To: References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> Message-ID: Can you tell me where i can download the JAXB 2.4 final module? I only found 2.4.0-b... which does not seem to be a final to me. I also tried to write to that list but i am waiting for approval, which seems pretty long now (maybe the owner is on vacation or so..). Do you know any other mailing list/resource i could contact to get that information? Otherwise i guess i have to go with xstream to not to be blocked for days now. Am 12.02.2019 um 01:28 schrieb Lance Andersen: > The last time I tried, you could not use JAXB 2.4 as a module but that > was before it went final. > > JAXB has dependencies on JAF so make sure you include that module. If > you are still struggling I would follow up on the JAXB dev mailing > list https://javaee.groups.io/g/metro for better guidance with JAXB 2.4 > > The documentation definitely needs some updates ?to 7.2.2 as it does > not even mention JAF or provide a current of example for using the > standalone JAXB as a module without upgrading the JDK implementation. > ?Also the release notes do not mention the runtime jar > https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html#jars > From sgehwolf at redhat.com Wed Feb 13 11:16:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 Feb 2019 12:16:18 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin Message-ID: Hi, As discussed in the RFR thread for JDK-8214796 it was suggested to rename the --strip-debug plugin so that --strip-debug could actually perform java debug symbols stripping *and* native debug symbols stripping at once. That's what this patch does. It renames --strip- debug to --strip-java-debug-symbols and --strip-debug just calls -- strip-java-debug-symbols behind the scenes. Note that --strip-debug-attributes as name would work for me too, but given that we are about to introduce --strip-native-debug-symbols, having the java strippping plugin with a similar name made sense to me. bug: https://bugs.openjdk.java.net/browse/JDK-8218913 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ Testing: jlink/jimage tests and jdk/submit (currently running). Thoughts? Thanks, Severin From Alan.Bateman at oracle.com Wed Feb 13 11:30:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 11:30:36 +0000 Subject: Problem with JAXBContext.newInstance In-Reply-To: References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> Message-ID: <33dec5e5-24ea-6f70-3ea9-e075c73a3eed@oracle.com> On 13/02/2019 11:14, Oliver Z. wrote: > Can you tell me where i can download the JAXB 2.4 final module? I only > found 2.4.0-b... which does not seem to be a final to me. > > I also tried to write to that list but i am waiting for approval, > which seems pretty long now (maybe the owner is on vacation or so..). > Do you know any other mailing list/resource i could contact to get > that information? Otherwise i guess i have to go with xstream to not > to be blocked for days now. I think you need to follow up on the Eclipse or Jakarta EE mailing lists about this as JAXB is not maintained here. From what I can tell from the release notes [1],? the Java EE JAXB project released 2.4.0 with changes to fix the issues they had deploying the JAXB runtime on the module path. It was a bit awkward before those changes in that you had to leave the runtime on the class path when running with java.xml.bind on the module path. I have no insight into why the download on the Eclipse site is 2.3.2 rather than the latest. -Alan [1] https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html#a-2-4-0 From oliver.zemann at gmail.com Wed Feb 13 12:05:19 2019 From: oliver.zemann at gmail.com (Oliver Z.) Date: Wed, 13 Feb 2019 13:05:19 +0100 Subject: Problem with JAXBContext.newInstance In-Reply-To: <33dec5e5-24ea-6f70-3ea9-e075c73a3eed@oracle.com> References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> <33dec5e5-24ea-6f70-3ea9-e075c73a3eed@oracle.com> Message-ID: <1b9c9b69-7e17-2849-0ece-4ef2afa29cfd@gmail.com> I found the solution. Pretty trivial, but probably unexpected when migrating. It is required to have 2 require entries in the module-info.java. I guess one for the API, and one for the implementation: requires java.xml.bind; requires com.sun.xml.bind; Then it works. Thanks for your effort! Am 13.02.19 um 12:30 schrieb Alan Bateman: > On 13/02/2019 11:14, Oliver Z. wrote: >> Can you tell me where i can download the JAXB 2.4 final module? I >> only found 2.4.0-b... which does not seem to be a final to me. >> >> I also tried to write to that list but i am waiting for approval, >> which seems pretty long now (maybe the owner is on vacation or so..). >> Do you know any other mailing list/resource i could contact to get >> that information? Otherwise i guess i have to go with xstream to not >> to be blocked for days now. > I think you need to follow up on the Eclipse or Jakarta EE mailing > lists about this as JAXB is not maintained here. From what I can tell > from the release notes [1],? the Java EE JAXB project released 2.4.0 > with changes to fix the issues they had deploying the JAXB runtime on > the module path. It was a bit awkward before those changes in that you > had to leave the runtime on the class path when running with > java.xml.bind on the module path. I have no insight into why the > download on the Eclipse site is 2.3.2 rather than the latest. > > -Alan > > [1] https://javaee.github.io/jaxb-v2/doc/user-guide/ch02.html#a-2-4-0 From Alan.Bateman at oracle.com Wed Feb 13 12:21:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 12:21:12 +0000 Subject: Problem with JAXBContext.newInstance In-Reply-To: <1b9c9b69-7e17-2849-0ece-4ef2afa29cfd@gmail.com> References: <4f47a16c-ad67-cd2f-5238-30b199d340c7@gmail.com> <35ddf9d5-bb8c-a852-e3cd-774a109d80ac@gmail.com> <33dec5e5-24ea-6f70-3ea9-e075c73a3eed@oracle.com> <1b9c9b69-7e17-2849-0ece-4ef2afa29cfd@gmail.com> Message-ID: <0b5dc559-62c7-8b7c-1a20-0296103ff5f7@oracle.com> On 13/02/2019 12:05, Oliver Z. wrote: > I found the solution. Pretty trivial, but probably unexpected when > migrating. It is required to have 2 require entries in the > module-info.java. I guess one for the API, and one for the > implementation: > > requires java.xml.bind; > requires com.sun.xml.bind; This doesn't look right (at least not unless you are using a implementation specific API exported by com.sun.xml.bind). This suggests to me that java,xml.bind is missing `uses java.xml.bind.JAXBContext` or com.sun.xml.bind is missing the equivalent `provides java.xml.bind.JAXBContext with ...`. That or whatever your environment isn't setting up the module path correctly. -Alan From mandy.chung at oracle.com Wed Feb 13 23:04:41 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2019 15:04:41 -0800 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: Message-ID: Hi Severin, Thanks for doing this. I review the webrev. You add a new DefaultStripDebugPlugin that will do the work. I have been assuming that this can be implemented as a jlink option that get translated into --strip-java-debug-symbols during the command line argument processing. I'm okay with --strip-java-debug-symbols. The help message from javac -g option: -g Generate all debugging info The other choice is --strip-java-debug-info and --strip-native-debug-info. We can settle the naming in the other thread to get others opinion. Mandy On 2/13/19 3:16 AM, Severin Gehwolf wrote: > Hi, > > As discussed in the RFR thread for JDK-8214796 it was suggested to > rename the --strip-debug plugin so that --strip-debug could actually > perform java debug symbols stripping *and* native debug symbols > stripping at once. That's what this patch does. It renames --strip- > debug to --strip-java-debug-symbols and --strip-debug just calls -- > strip-java-debug-symbols behind the scenes. > > Note that --strip-debug-attributes as name would work for me too, but > given that we are about to introduce --strip-native-debug-symbols, > having the java strippping plugin with a similar name made sense to me. > > bug: https://bugs.openjdk.java.net/browse/JDK-8218913 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ > > Testing: jlink/jimage tests and jdk/submit (currently running). > > Thoughts? > > Thanks, > Severin > From mandy.chung at oracle.com Wed Feb 13 23:36:32 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Feb 2019 15:36:32 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: On 2/13/19 1:04 AM, Severin Gehwolf wrote: >> --strip-native-debug-symbols no-keep-debuginfo > --strip-native-debug-symbols strip-debuginfo > --strip-native-debug-symbols remove-debuginfo > > It would avoid using negation. What about 'omit', i.e. --strip-native-debug-symbols omit-debuginfo --strip-native-debug-symbols keep-debuginfo= > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > strip-java-debug-symbols be acceptable? My thinking is that it would > have nice symmetry with --strip-native-debug-symbols. Thoughts? --strip-native-debug-symbols is okay. Having a second thought, javac -g and gcc -g both say "debugging information". I think we could go with: --strip-java-debug-info --strip-native-debug-info omit-debuginfo --strip-native-debug-info keep-debuginfo= unless anyone thinks `-debug-symbols` is better? The options are getting pretty good now. Mandy From s.2016.kay at gmail.com Thu Feb 14 00:33:29 2019 From: s.2016.kay at gmail.com (Ess Kay) Date: Thu, 14 Feb 2019 11:33:29 +1100 Subject: Reading Java 9 bootstrap class bytecode from Java 12? Message-ID: Is there any way of accessing Java 9's bootstrap classes from within Java 12 to access Java 9's bootstrap classes? If run using Java 12, the snippet below always finds the Java 12 file system rather than the required Java 9 file system. My immediate issue is that I am inappropriately finding java.lang.constant.Constable when searching for the implemented interfaces of java.lang.invoke.MethodHandle in Java 9 bytecode. String targetImage = <...Java9_HOME...> URL url = Paths.get(targetImage, "lib", "jrt-fs.jar").toUri().toURL(); URLClassLoader loader = new URLClassLoader(new URL[] { url }); FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), Collections.emptyMap(), loader); From Alan.Bateman at oracle.com Thu Feb 14 07:31:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 07:31:03 +0000 Subject: Reading Java 9 bootstrap class bytecode from Java 12? In-Reply-To: References: Message-ID: <84168302-64ea-45b3-55ac-bb3f75936ecd@oracle.com> On 14/02/2019 00:33, Ess Kay wrote: > Is there any way of accessing Java 9's bootstrap classes from within Java > 12 to access Java 9's bootstrap classes? If run using Java 12, the snippet > below always finds the Java 12 file system rather than the required Java 9 > file system. My immediate issue is that I am inappropriately finding > java.lang.constant.Constable when searching for the implemented interfaces > of java.lang.invoke.MethodHandle in Java 9 bytecode. > > String targetImage = <...Java9_HOME...> > URL url = Paths.get(targetImage, "lib", "jrt-fs.jar").toUri().toURL(); > URLClassLoader loader = new URLClassLoader(new URL[] { url }); > FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), > Collections.emptyMap(), loader); You are using a URLClassLoader and I assume it's delegating so you are loading the jrt file system provider from the current runtime, not from jrt-fs.jar in the target runtime. Running with -verbose should confirm that. The simplest way to cross target is to specify the java.home parameter when creating the file system, e.g: String javaHome = FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", javaHome)); -Alan From sgehwolf at redhat.com Thu Feb 14 08:27:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Feb 2019 09:27:12 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <529c7a3d7e6095e213498150cb5fbb50e2342f36.camel@redhat.com> On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > --strip-native-debug-symbols no-keep-debuginfo > > --strip-native-debug-symbols strip-debuginfo > > --strip-native-debug-symbols remove-debuginfo > > > > It would avoid using negation. > > What about 'omit', i.e. > > --strip-native-debug-symbols omit-debuginfo > --strip-native-debug-symbols keep-debuginfo= I like it. Good for me. > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > strip-java-debug-symbols be acceptable? My thinking is that it would > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > --strip-native-debug-symbols is okay. > > Having a second thought, javac -g and gcc -g both say "debugging > information". I think we could go with: > > --strip-java-debug-info > --strip-native-debug-info omit-debuginfo > --strip-native-debug-info keep-debuginfo= > > unless anyone thinks `-debug-symbols` is better? > > The options are getting pretty good now. +1. debug-info over debug-symbols is good for me. Thanks, Severin From sgehwolf at redhat.com Thu Feb 14 09:04:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Feb 2019 10:04:54 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: Message-ID: <04e103b0a33e6a865dae4d8a94fa86640a5adb81.camel@redhat.com> Hi Mandy, On Wed, 2019-02-13 at 15:04 -0800, Mandy Chung wrote: > Hi Severin, > > Thanks for doing this. I review the webrev. Thanks for the review! > You add a new DefaultStripDebugPlugin that will do the work. > I have been assuming that this can be implemented as a jlink option > that get translated into --strip-java-debug-symbols during > the command line argument processing. The reason I've opted for this approach was the intention to hook -- strip-debug up with not only --strip-java-debug-symbols, but also -- strip-native-debug-symbols as well once that gets in. The analogy to the compress plugin applies here. Using this approach will make that additional hooking up easier. Though, thinking about this some more -- strip-native-debug-info will be linux-only, so I'll have to ponder a bit about how to make use of that platform-specific option without breaking platforms which don't have it. > I'm okay with --strip-java-debug-symbols. The help message from > javac -g option: > -g Generate all debugging info > > The other choice is --strip-java-debug-info and > --strip-native-debug-info. We can settle the naming in the other thread > to get others > opinion. As indicated in the other thread, I'd be happy to call it --strip-java- debug-info and --strip-native-debug-info. I'll wait for the other thread to settle before I'll update the webrev. Thanks, Severin > Mandy > > On 2/13/19 3:16 AM, Severin Gehwolf wrote: > > Hi, > > > > As discussed in the RFR thread for JDK-8214796 it was suggested to > > rename the --strip-debug plugin so that --strip-debug could actually > > perform java debug symbols stripping *and* native debug symbols > > stripping at once. That's what this patch does. It renames --strip- > > debug to --strip-java-debug-symbols and --strip-debug just calls -- > > strip-java-debug-symbols behind the scenes. > > > > Note that --strip-debug-attributes as name would work for me too, but > > given that we are about to introduce --strip-native-debug-symbols, > > having the java strippping plugin with a similar name made sense to me. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8218913 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ > > > > Testing: jlink/jimage tests and jdk/submit (currently running). > > > > Thoughts? > > > > Thanks, > > Severin > > From Alan.Bateman at oracle.com Thu Feb 14 15:26:35 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 15:26:35 +0000 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: Message-ID: <9f5a6074-e37e-3342-e602-f55bb23a1e1d@oracle.com> On 13/02/2019 11:16, Severin Gehwolf wrote: > Hi, > > As discussed in the RFR thread for JDK-8214796 it was suggested to > rename the --strip-debug plugin so that --strip-debug could actually > perform java debug symbols stripping *and* native debug symbols > stripping at once. That's what this patch does. It renames --strip- > debug to --strip-java-debug-symbols and --strip-debug just calls -- > strip-java-debug-symbols behind the scenes. > > Note that --strip-debug-attributes as name would work for me too, but > given that we are about to introduce --strip-native-debug-symbols, > having the java strippping plugin with a similar name made sense to me. > > bug: https://bugs.openjdk.java.net/browse/JDK-8218913 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ > I skimmed through the webrev and the approach looks good. I don't have a strong opinion on the naming but the previous suggestion to use --strip-java-debug-attributes seems slightly better, if only it gives a hint that it strips the LVT and LLVT class file attributes. If the "strip the world" option is --strip-debug-info then it could imply both --strip-java-debug-attributes and --strip-native-debug-symbols without needing to unify the terminology. -Alan. From sgehwolf at redhat.com Thu Feb 14 16:38:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Feb 2019 17:38:11 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <9f5a6074-e37e-3342-e602-f55bb23a1e1d@oracle.com> References: <9f5a6074-e37e-3342-e602-f55bb23a1e1d@oracle.com> Message-ID: Hi Alan, On Thu, 2019-02-14 at 15:26 +0000, Alan Bateman wrote: > On 13/02/2019 11:16, Severin Gehwolf wrote: > > Hi, > > > > As discussed in the RFR thread for JDK-8214796 it was suggested to > > rename the --strip-debug plugin so that --strip-debug could actually > > perform java debug symbols stripping *and* native debug symbols > > stripping at once. That's what this patch does. It renames --strip- > > debug to --strip-java-debug-symbols and --strip-debug just calls -- > > strip-java-debug-symbols behind the scenes. > > > > Note that --strip-debug-attributes as name would work for me too, but > > given that we are about to introduce --strip-native-debug-symbols, > > having the java strippping plugin with a similar name made sense to me. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8218913 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ > > > I skimmed through the webrev and the approach looks good. Thanks for the review! > I don't have a strong opinion on the naming but the previous suggestion > to use --strip-java-debug-attributes seems slightly better, if only it > gives a hint that it strips the LVT and LLVT class file attributes. If > the "strip the world" option is --strip-debug-info then it could imply > both --strip-java-debug-attributes and --strip-native-debug-symbols > without needing to unify the terminology. A bit of clarification would be needed here I think: 1) The current option is called '--strip-debug', not '--strip-debug-info'. Did you mean to say to rename --strip-debug to --strip-debug-info too? Perhaps make '--strip-debug' and alias for '--strip-debug-info'? 2) --strip-debug-attributes as a replacement for what --strip-debug does today was discussed. The above patch uses --strip-java-debug-symbols. Now you say --strip-java-debug-attributes. Is that the name I should be using? Currently, my understanding is to go with: --strip-debug => --strip-java-debug-attributes and let --strip-debug just call the --strip-java-debug-attributes plugin. --strip-debug-info would not exist (as it doesn't exist now). Thanks, Severin From mandy.chung at oracle.com Thu Feb 14 19:11:49 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2019 11:11:49 -0800 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <04e103b0a33e6a865dae4d8a94fa86640a5adb81.camel@redhat.com> References: <04e103b0a33e6a865dae4d8a94fa86640a5adb81.camel@redhat.com> Message-ID: On 2/14/19 1:04 AM, Severin Gehwolf wrote: > Hi Mandy, > >> You add a new DefaultStripDebugPlugin that will do the work. >> I have been assuming that this can be implemented as a jlink option >> that get translated into --strip-java-debug-symbols during >> the command line argument processing. > > The reason I've opted for this approach was the intention to hook -- > strip-debug up with not only --strip-java-debug-symbols, but also -- > strip-native-debug-symbols as well once that gets in. The analogy to > the compress plugin applies here. Using this approach will make that > additional hooking up easier. Though, thinking about this some more -- > strip-native-debug-info will be linux-only, so I'll have to ponder a > bit about how to make use of that platform-specific option without > breaking platforms which don't have it. Good point. That's the merit of this approach which makes it easier to hook up a platform-specific plugin that may or may not exist. Mandy From mandy.chung at oracle.com Thu Feb 14 19:26:42 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Feb 2019 11:26:42 -0800 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <9f5a6074-e37e-3342-e602-f55bb23a1e1d@oracle.com> Message-ID: <723018ff-d9c7-3361-0cd7-ba2a18325751@oracle.com> On 2/14/19 8:38 AM, Severin Gehwolf wrote: > A bit of clarification would be needed here I think: > > 1) > The current option is called '--strip-debug', not '--strip-debug-info'. > Did you mean to say to rename --strip-debug to --strip-debug-info too? > Perhaps make '--strip-debug' and alias for '--strip-debug-info'? > > 2) > --strip-debug-attributes as a replacement for what --strip-debug does > today was discussed. The above patch uses --strip-java-debug-symbols. > Now you say --strip-java-debug-attributes. Is that the name I should be > using? > > Currently, my understanding is to go with: > > --strip-debug => --strip-java-debug-attributes and let --strip-debug > just call the --strip-java-debug-attributes plugin. --strip-debug-info > would not exist (as it doesn't exist now). --strip-debug is the documented jlink option and I don't think we need a new --strip-debug-info option. --strip-java-debug-attributes and --strip-native-debug-symbols are very clear. I'm happy to go with them. thanks Mandy From Alan.Bateman at oracle.com Thu Feb 14 20:46:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Feb 2019 20:46:45 +0000 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <9f5a6074-e37e-3342-e602-f55bb23a1e1d@oracle.com> Message-ID: <93ee4c2f-266b-8b9d-bddb-96efbcc59a0d@oracle.com> On 14/02/2019 16:38, Severin Gehwolf wrote: > : > A bit of clarification would be needed here I think: > > 1) > The current option is called '--strip-debug', not '--strip-debug-info'. > Did you mean to say to rename --strip-debug to --strip-debug-info too? > Perhaps make '--strip-debug' and alias for '--strip-debug-info'? Sorry, there a typo in my mail, I meant `--strip-debug`. > > Currently, my understanding is to go with: > > --strip-debug => --strip-java-debug-attributes and let --strip-debug > just call the --strip-java-debug-attributes plugin. --strip-debug-info > would not exist (as it doesn't exist now). > That seems good to me. I see Mandy is on board with this plan and naming too. -Alan. From sgehwolf at redhat.com Fri Feb 15 12:15:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Feb 2019 13:15:18 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: Message-ID: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> Hi Mandy, On Wed, 2019-02-13 at 15:04 -0800, Mandy Chung wrote: > Hi Severin, > > Thanks for doing this. I review the webrev. Here is the latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/02/webrev/ It uses --strip-java-debug-attributes as discussed in [1]. The --list- plugins output for --strip-debug and --strip-java-debug-attributes reads as follows: Plugin Name: strip-debug Option: --strip-debug Description: Strip debug information from the output image Plugin Name: strip-java-debug-attributes Option: --strip-java-debug-attributes Description: Strip Java debug attributes from classes in the output image Testing: test/jdk/tools/jlink and jdk/submit. Thoughts? Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2019-February/014152.html > You add a new DefaultStripDebugPlugin that will do the work. > I have been assuming that this can be implemented as a jlink option > that get translated into --strip-java-debug-symbols during > the command line argument processing. > > I'm okay with --strip-java-debug-symbols. The help message from > javac -g option: > -g Generate all debugging info > > The other choice is --strip-java-debug-info and > --strip-native-debug-info. We can settle the naming in the other > thread > to get others > opinion. > > Mandy > > On 2/13/19 3:16 AM, Severin Gehwolf wrote: > > Hi, > > > > As discussed in the RFR thread for JDK-8214796 it was suggested to > > rename the --strip-debug plugin so that --strip-debug could > > actually > > perform java debug symbols stripping *and* native debug symbols > > stripping at once. That's what this patch does. It renames --strip- > > debug to --strip-java-debug-symbols and --strip-debug just calls -- > > strip-java-debug-symbols behind the scenes. > > > > Note that --strip-debug-attributes as name would work for me too, > > but > > given that we are about to introduce --strip-native-debug-symbols, > > having the java strippping plugin with a similar name made sense to > > me. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8218913 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/01/webrev/ > > > > Testing: jlink/jimage tests and jdk/submit (currently running). > > > > Thoughts? > > > > Thanks, > > Severin > > From Alan.Bateman at oracle.com Fri Feb 15 15:57:16 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2019 15:57:16 +0000 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> Message-ID: <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> On 15/02/2019 12:15, Severin Gehwolf wrote: > : > Here is the latest webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/02/webrev/ > > It uses --strip-java-debug-attributes as discussed in [1]. The --list- > plugins output for --strip-debug and --strip-java-debug-attributes > reads as follows: > > Plugin Name: strip-debug > Option: --strip-debug > Description: Strip debug information from the output image > > Plugin Name: strip-java-debug-attributes > Option: --strip-java-debug-attributes > Description: Strip Java debug attributes from classes in the output image > This looks good to me. One minor point is that try to discourage @author tags in source files these days. -Alan From sgehwolf at redhat.com Fri Feb 15 16:12:23 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Feb 2019 17:12:23 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> Message-ID: Hi Alan, On Fri, 2019-02-15 at 15:57 +0000, Alan Bateman wrote: > On 15/02/2019 12:15, Severin Gehwolf wrote: > > : > > Here is the latest webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/02/webrev/ > > > > It uses --strip-java-debug-attributes as discussed in [1]. The --list- > > plugins output for --strip-debug and --strip-java-debug-attributes > > reads as follows: > > > > Plugin Name: strip-debug > > Option: --strip-debug > > Description: Strip debug information from the output image > > > > Plugin Name: strip-java-debug-attributes > > Option: --strip-java-debug-attributes > > Description: Strip Java debug attributes from classes in the output image > > > This looks good to me. One minor point is that try to discourage @author > tags in source files these days. Thanks for the review! I've remove the @author tag: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ Thanks, Severin From sgehwolf at redhat.com Fri Feb 15 17:01:27 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Feb 2019 18:01:27 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> Message-ID: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Hi Alan, Mandy, Here is the next round of this change: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ It now also has tests which don't require objcopy to be present on test machines as well as being integrated with --strip-debug (once JDK- 8218913 is pushed). --list-plugins help output for --strip-native- debug-symbols now reads: ----->8------------------------- Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any). This plugin requires at least one option: objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. omit-debuginfo: Do not keep debug info files. Defaults to true. keep-debuginfo[=]: Keep debug info files in .. Defaults to .debuginfo Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy --strip-native-debug-symbols=omit-debuginfo --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy ----->8------------------------- Testing: jdk.jlink tests jdk/submit (ongoing), added tests: DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest Note: IntegrationTest needed a heap size bump as this now runs StripNativeDebugSymbolsPluginTest on some systems. Especially with --with-native-debug-symbols=internal builds this can eat some memory. Please let me know what you think. Thanks, Severin On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > --strip-native-debug-symbols no-keep-debuginfo > > --strip-native-debug-symbols strip-debuginfo > > --strip-native-debug-symbols remove-debuginfo > > > > It would avoid using negation. > > What about 'omit', i.e. > > --strip-native-debug-symbols omit-debuginfo > --strip-native-debug-symbols keep-debuginfo= > > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > strip-java-debug-symbols be acceptable? My thinking is that it would > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > --strip-native-debug-symbols is okay. > > Having a second thought, javac -g and gcc -g both say "debugging > information". I think we could go with: > > --strip-java-debug-info > --strip-native-debug-info omit-debuginfo > --strip-native-debug-info keep-debuginfo= > > unless anyone thinks `-debug-symbols` is better? > > The options are getting pretty good now. > > Mandy From Alan.Bateman at oracle.com Fri Feb 15 19:04:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Feb 2019 19:04:28 +0000 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> Message-ID: <7a450e56-e80b-059f-3ae6-b05a0e9aa61f@oracle.com> On 15/02/2019 16:12, Severin Gehwolf wrote: > : > Thanks for the review! I've remove the @author tag: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ > Looks good. Are you planning to do submit a CSR for this? (CLI options are a supported/documented interface). -Alan From mikael.vidstedt at oracle.com Fri Feb 15 21:24:15 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:24:15 -0800 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly Message-ID: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. Cheers, Mikael From james.laskey at oracle.com Fri Feb 15 21:58:29 2019 From: james.laskey at oracle.com (James Laskey) Date: Fri, 15 Feb 2019 17:58:29 -0400 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> Message-ID: <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> I wonder if you should flag overflow so no attempt is made to search with a bogus path. It?s not necessary but prevent future misunderstandings. Sent from my iPhone > On Feb 15, 2019, at 5:24 PM, Mikael Vidstedt wrote: > > > Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ > > > In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Fri Feb 15 22:31:18 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 14:31:18 -0800 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> Message-ID: This is interesting. I agree that the code should handle an overflow in a better way, throwing an exception seems like the reasonable thing to do. I started looking at doing exactly that. However, that also made me have a look at how this code is actually used, and.. It?s not obvious that it actually is.. AFAICT, ImageFileReader::location_path is only used from JIMAGE_ResourcePath (in jimage.cpp). The only ?user? I can find of that function in the JDK is in hotspot: src/hotspot/share/classfile/classLoader.cpp:static JImage_ResourcePath_t JImageResourcePath = NULL; src/hotspot/share/classfile/classLoader.cpp: JImageResourcePath = CAST_TO_FN_PTR(JImage_ResourcePath_t, os::dll_lookup(handle, "JIMAGE_ResourcePath")); src/hotspot/share/classfile/classLoader.cpp: guarantee(JImageResourcePath != NULL, "function JIMAGE_ResourcePath not found?); That?s the declaration of a variable, the initialization of it, and the check to make sure the lookup actually succeeded. However, the variable isn?t actually used anywhere after that. Is this dead code which should just be removed instead? Or is JIMAGE_ResourcePath considered exported? Can (non-JDK) native code expect to find and use it? Cheers, Mikael > On Feb 15, 2019, at 1:58 PM, James Laskey wrote: > > I wonder if you should flag overflow so no attempt is made to search with a bogus path. It?s not necessary but prevent future misunderstandings. > > Sent from my iPhone > >> On Feb 15, 2019, at 5:24 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ >> >> >> In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. >> >> Cheers, >> Mikael >> > From mikael.vidstedt at oracle.com Fri Feb 15 22:35:37 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 14:35:37 -0800 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> Message-ID: <7C502711-A661-4B4C-8135-8EAFEA0C97E3@oracle.com> > On Feb 15, 2019, at 2:31 PM, Mikael Vidstedt wrote: > > > This is interesting. I agree that the code should handle an overflow in a better way, throwing an exception seems like the reasonable thing to do. I started looking at doing exactly that. Sorry, throwing an exception isn?t a reasonable thing to do, it would have to be flagged some other way, however, the more important question is still: is this code dead? > > However, that also made me have a look at how this code is actually used, and.. > > It?s not obvious that it actually is.. > > AFAICT, ImageFileReader::location_path is only used from JIMAGE_ResourcePath (in jimage.cpp). The only ?user? I can find of that function in the JDK is in hotspot: > > src/hotspot/share/classfile/classLoader.cpp:static JImage_ResourcePath_t JImageResourcePath = NULL; > src/hotspot/share/classfile/classLoader.cpp: JImageResourcePath = CAST_TO_FN_PTR(JImage_ResourcePath_t, os::dll_lookup(handle, "JIMAGE_ResourcePath")); > src/hotspot/share/classfile/classLoader.cpp: guarantee(JImageResourcePath != NULL, "function JIMAGE_ResourcePath not found?); > > That?s the declaration of a variable, the initialization of it, and the check to make sure the lookup actually succeeded. However, the variable isn?t actually used anywhere after that. > > Is this dead code which should just be removed instead? Or is JIMAGE_ResourcePath considered exported? Can (non-JDK) native code expect to find and use it? > > Cheers, > Mikael > >> On Feb 15, 2019, at 1:58 PM, James Laskey wrote: >> >> I wonder if you should flag overflow so no attempt is made to search with a bogus path. It?s not necessary but prevent future misunderstandings. >> >> Sent from my iPhone >> >>> On Feb 15, 2019, at 5:24 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ >>> >>> >>> In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. >>> >>> Cheers, >>> Mikael >>> >> > From james.laskey at oracle.com Fri Feb 15 22:39:44 2019 From: james.laskey at oracle.com (James Laskey) Date: Fri, 15 Feb 2019 18:39:44 -0400 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> Message-ID: <37208C94-100C-4082-A779-0CB5379F43B3@oracle.com> The only user IIRC is the native class loader. It?s possible, due to the evolution of the API, that this entry is no longer used. Kill and verify. Sent from my iPhone > On Feb 15, 2019, at 6:31 PM, Mikael Vidstedt wrote: > > > This is interesting. I agree that the code should handle an overflow in a better way, throwing an exception seems like the reasonable thing to do. I started looking at doing exactly that. > > However, that also made me have a look at how this code is actually used, and.. > > It?s not obvious that it actually is.. > > AFAICT, ImageFileReader::location_path is only used from JIMAGE_ResourcePath (in jimage.cpp). The only ?user? I can find of that function in the JDK is in hotspot: > > src/hotspot/share/classfile/classLoader.cpp:static JImage_ResourcePath_t JImageResourcePath = NULL; > src/hotspot/share/classfile/classLoader.cpp: JImageResourcePath = CAST_TO_FN_PTR(JImage_ResourcePath_t, os::dll_lookup(handle, "JIMAGE_ResourcePath")); > src/hotspot/share/classfile/classLoader.cpp: guarantee(JImageResourcePath != NULL, "function JIMAGE_ResourcePath not found?); > > That?s the declaration of a variable, the initialization of it, and the check to make sure the lookup actually succeeded. However, the variable isn?t actually used anywhere after that. > > Is this dead code which should just be removed instead? Or is JIMAGE_ResourcePath considered exported? Can (non-JDK) native code expect to find and use it? > > Cheers, > Mikael > >> On Feb 15, 2019, at 1:58 PM, James Laskey wrote: >> >> I wonder if you should flag overflow so no attempt is made to search with a bogus path. It?s not necessary but prevent future misunderstandings. >> >> Sent from my iPhone >> >>> On Feb 15, 2019, at 5:24 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ >>> >>> >>> In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. >>> >>> Cheers, >>> Mikael >>> >> > From mikael.vidstedt at oracle.com Sat Feb 16 00:39:16 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 16:39:16 -0800 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: <37208C94-100C-4082-A779-0CB5379F43B3@oracle.com> References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> <21E03402-8EAE-47A1-AAD3-26E50127D981@oracle.com> <37208C94-100C-4082-A779-0CB5379F43B3@oracle.com> Message-ID: <1E8937D5-7AA4-4B34-8F7F-8C25F79B8F78@oracle.com> FWIW, this change, which removes ResourcePath etc. also passes tier1: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.01/open/webrev/ So if that function isn?t meant to be used from outside the JDK I?m pretty sure the code is indeed dead and should just be removed. Cheers, Mikael > On Feb 15, 2019, at 2:39 PM, James Laskey wrote: > > The only user IIRC is the native class loader. It?s possible, due to the evolution of the API, that this entry is no longer used. Kill and verify. > > Sent from my iPhone > >> On Feb 15, 2019, at 6:31 PM, Mikael Vidstedt wrote: >> >> >> This is interesting. I agree that the code should handle an overflow in a better way, throwing an exception seems like the reasonable thing to do. I started looking at doing exactly that. >> >> However, that also made me have a look at how this code is actually used, and.. >> >> It?s not obvious that it actually is.. >> >> AFAICT, ImageFileReader::location_path is only used from JIMAGE_ResourcePath (in jimage.cpp). The only ?user? I can find of that function in the JDK is in hotspot: >> >> src/hotspot/share/classfile/classLoader.cpp:static JImage_ResourcePath_t JImageResourcePath = NULL; >> src/hotspot/share/classfile/classLoader.cpp: JImageResourcePath = CAST_TO_FN_PTR(JImage_ResourcePath_t, os::dll_lookup(handle, "JIMAGE_ResourcePath")); >> src/hotspot/share/classfile/classLoader.cpp: guarantee(JImageResourcePath != NULL, "function JIMAGE_ResourcePath not found?); >> >> That?s the declaration of a variable, the initialization of it, and the check to make sure the lookup actually succeeded. However, the variable isn?t actually used anywhere after that. >> >> Is this dead code which should just be removed instead? Or is JIMAGE_ResourcePath considered exported? Can (non-JDK) native code expect to find and use it? >> >> Cheers, >> Mikael >> >>> On Feb 15, 2019, at 1:58 PM, James Laskey wrote: >>> >>> I wonder if you should flag overflow so no attempt is made to search with a bogus path. It?s not necessary but prevent future misunderstandings. >>> >>> Sent from my iPhone >>> >>>> On Feb 15, 2019, at 5:24 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 >>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ >>>> >>>> >>>> In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. >>>> >>>> Cheers, >>>> Mikael >>>> >>> >> > From mandy.chung at oracle.com Sat Feb 16 07:27:04 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Feb 2019 23:27:04 -0800 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> Message-ID: <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> On 2/15/19 8:12 AM, Severin Gehwolf wrote: > Thanks for the review! I've remove the @author tag: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ Looks good. As Alan said, this needs a CSR to document the new plugin command-line option. thanks Mandy From Alan.Bateman at oracle.com Mon Feb 18 08:03:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Feb 2019 08:03:37 +0000 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> Message-ID: On 15/02/2019 21:24, Mikael Vidstedt wrote: > Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ > > > In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. > The jrtfs tests cover this area, the path to specify to jtreg is jdk/jdk/internal/jrtfs. I skimmed through the changes and all red looks good :-)? I assume the bug description can be changed as it's now about removing unused jimage functions rather than changes to works with a newer version of gcc. -Alan From magnus.ihse.bursie at oracle.com Mon Feb 18 08:32:17 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 09:32:17 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: > 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : > > Hi Alan, Mandy, > > Here is the next round of this change: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ Looks good from the build PoV, with one minor nit: In JtregNativeJdk.gmk, please use the new construct: ifeq ($(call isTargetOs, linux), true) /Magnus > > It now also has tests which don't require objcopy to be present on test > machines as well as being integrated with --strip-debug (once JDK- > 8218913 is pushed). --list-plugins help output for --strip-native- > debug-symbols now reads: > > ----->8------------------------- > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > omit-debuginfo: Do not keep debug info files. Defaults to true. > keep-debuginfo[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=omit-debuginfo > --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy > ----->8------------------------- > > Testing: jdk.jlink tests jdk/submit (ongoing), added tests: > DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest > > Note: IntegrationTest needed a heap size bump as this now runs > StripNativeDebugSymbolsPluginTest on some systems. Especially with > --with-native-debug-symbols=internal builds this can eat some > memory. > > Please let me know what you think. > > Thanks, > Severin > >> On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: >> On 2/13/19 1:04 AM, Severin Gehwolf wrote: >>>> --strip-native-debug-symbols no-keep-debuginfo >>> --strip-native-debug-symbols strip-debuginfo >>> --strip-native-debug-symbols remove-debuginfo >>> >>> It would avoid using negation. >> >> What about 'omit', i.e. >> >> --strip-native-debug-symbols omit-debuginfo >> --strip-native-debug-symbols keep-debuginfo= >> >>> Sure. I've filed JDK-8218913 for doing this first. Would a name of -- >>> strip-java-debug-symbols be acceptable? My thinking is that it would >>> have nice symmetry with --strip-native-debug-symbols. Thoughts? >> >> --strip-native-debug-symbols is okay. >> >> Having a second thought, javac -g and gcc -g both say "debugging >> information". I think we could go with: >> >> --strip-java-debug-info >> --strip-native-debug-info omit-debuginfo >> --strip-native-debug-info keep-debuginfo= >> >> unless anyone thinks `-debug-symbols` is better? >> >> The options are getting pretty good now. >> >> Mandy > From sgehwolf at redhat.com Mon Feb 18 09:50:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Feb 2019 10:50:29 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> Message-ID: On Fri, 2019-02-15 at 23:27 -0800, Mandy Chung wrote: > On 2/15/19 8:12 AM, Severin Gehwolf wrote: > > Thanks for the review! I've remove the @author tag: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ > > Looks good. As Alan said, this needs a CSR to document the new plugin > command-line option. Thanks. CSR has been filed here: https://bugs.openjdk.java.net/browse/JDK-8219207 Cheers, Severin From Alan.Bateman at oracle.com Mon Feb 18 10:10:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Feb 2019 10:10:49 +0000 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> Message-ID: <7428b936-11a1-9da4-ef2a-5e36ff6155c7@oracle.com> On 18/02/2019 09:50, Severin Gehwolf wrote: > : > Thanks. CSR has been filed here: > https://bugs.openjdk.java.net/browse/JDK-8219207 > The interface change is to add --strip-java-debug-attributes so it might be better to change the synopsis and the summary to make this clearer. Also in the specification section it would be better to include the usage message for the new option rather than a link to the webrev (as the webrev could disappear at any time and so not useful to anyone looking at the CSR at some future time). -Alan From sgehwolf at redhat.com Mon Feb 18 10:37:06 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Feb 2019 11:37:06 +0100 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: <7428b936-11a1-9da4-ef2a-5e36ff6155c7@oracle.com> References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> <7428b936-11a1-9da4-ef2a-5e36ff6155c7@oracle.com> Message-ID: <0b2133dbd06ed9c6186d061db592c267faf387b1.camel@redhat.com> On Mon, 2019-02-18 at 10:10 +0000, Alan Bateman wrote: > On 18/02/2019 09:50, Severin Gehwolf wrote: > > : > > Thanks. CSR has been filed here: > > https://bugs.openjdk.java.net/browse/JDK-8219207 > > > The interface change is to add --strip-java-debug-attributes so it > might be better to change the synopsis and the summary to make this > clearer. Also in the specification section it would be better to > include the usage message for the new option rather than a link to > the webrev (as the webrev could disappear at any time and so not > useful to anyone looking at the CSR at some future time). OK. Thanks, Alan. I've updated it accordingly. Thanks, Severin From sgehwolf at redhat.com Mon Feb 18 11:02:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Feb 2019 12:02:54 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> Hi Magnus, On Mon, 2019-02-18 at 09:32 +0100, Magnus Ihse Bursie wrote: > > 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : > > > > Hi Alan, Mandy, > > > > Here is the next round of this change: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ > > Looks good from the build PoV, with one minor nit: In > JtregNativeJdk.gmk, please use the new construct: > > ifeq ($(call isTargetOs, linux), true) Right. Thanks for this. I've updated it locally. The hunk in JtregNaitveJdk.gmk now reads: diff --git a/make/test/JtregNativeJdk.gmk b/make/test/JtregNativeJdk.gmk --- a/make/test/JtregNativeJdk.gmk +++ b/make/test/JtregNativeJdk.gmk @@ -82,6 +82,14 @@ BUILD_JDK_JTREG_EXCLUDE += exeJniInvocationTest.c endif +ifeq ($(call isTargetOs, linux), true) + # Unconditionally compile with debug symbols and don't ever perform + # stripping during the test libraries' build. + BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libFib := -g + BUILD_JDK_JTREG_LIBRARIES_STRIP_SYMBOLS_libFib := false +endif + + $(eval $(call SetupTestFilesCompilation, BUILD_JDK_JTREG_LIBRARIES, \ TYPE := LIBRARY, \ SOURCE_DIRS := $(BUILD_JDK_JTREG_NATIVE_SRC), \ Thanks, Severin From magnus.ihse.bursie at oracle.com Mon Feb 18 11:05:27 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Feb 2019 12:05:27 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <80c48f6909765e95700db49ed040ce02be9b692f.camel@redhat.com> Message-ID: <03abff3e-5dec-d8dd-185b-4f7566da7c2d@oracle.com> On 2019-02-18 12:02, Severin Gehwolf wrote: > Hi Magnus, > > On Mon, 2019-02-18 at 09:32 +0100, Magnus Ihse Bursie wrote: >>> 15 feb. 2019 kl. 18:01 skrev Severin Gehwolf : >>> >>> Hi Alan, Mandy, >>> >>> Here is the next round of this change: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ >> Looks good from the build PoV, with one minor nit: In >> JtregNativeJdk.gmk, please use the new construct: >> >> ifeq ($(call isTargetOs, linux), true) > Right. Thanks for this. I've updated it locally. The hunk in > JtregNaitveJdk.gmk now reads: > > diff --git a/make/test/JtregNativeJdk.gmk b/make/test/JtregNativeJdk.gmk > --- a/make/test/JtregNativeJdk.gmk > +++ b/make/test/JtregNativeJdk.gmk > @@ -82,6 +82,14 @@ > BUILD_JDK_JTREG_EXCLUDE += exeJniInvocationTest.c > endif > > +ifeq ($(call isTargetOs, linux), true) > + # Unconditionally compile with debug symbols and don't ever perform > + # stripping during the test libraries' build. > + BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libFib := -g > + BUILD_JDK_JTREG_LIBRARIES_STRIP_SYMBOLS_libFib := false > +endif > + > + > $(eval $(call SetupTestFilesCompilation, BUILD_JDK_JTREG_LIBRARIES, \ > TYPE := LIBRARY, \ > SOURCE_DIRS := $(BUILD_JDK_JTREG_NATIVE_SRC), \ > > Thanks, > Severin +1 /Magnus > From mikael.vidstedt at oracle.com Tue Feb 19 19:48:24 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 19 Feb 2019 11:48:24 -0800 Subject: RFR(S): 8219142: Make libjimage strncpy uses GCC 8.x friendly In-Reply-To: References: <9C5D4A2F-1080-4A91-858E-5198C4E4A7FA@oracle.com> Message-ID: > On Feb 18, 2019, at 12:03 AM, Alan Bateman wrote: > > On 15/02/2019 21:24, Mikael Vidstedt wrote: >> Please review this change which addresses some warnings generated by GCC 8.2 related to the uses of strncpy in libjimage/imageFile.cpp. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219142 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8219142/webrev.00/open/webrev/ >> >> >> In addition to feedback on the change itself, I?m taking suggestions on what tests to run. An earlier version of the change passed the typical tier1 testing. I?m going to run tier1 on this version as well, but let me know if there are additional tests I should run. >> > The jrtfs tests cover this area, the path to specify to jtreg is jdk/jdk/internal/jrtfs. Thanks! I ran the jrtfs tests (all of tier2 even) and they all pass. > I skimmed through the changes and all red looks good :-) I assume the bug description can be changed as it's now about removing unused jimage functions rather than changes to works with a newer version of gcc. Updated the summary to reflect the new charter of the enhancement. Can I please get a review from somebody in the runtime team as well for the hotspot changes? Cheers, Mikael From mandy.chung at oracle.com Wed Feb 20 02:44:33 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Feb 2019 18:44:33 -0800 Subject: RFR: 8218913: Rename --strip-debug jlink plugin In-Reply-To: References: <0f9c0df096706418b01e84b6308439b4f7ce3e2d.camel@redhat.com> <6b51393b-3cba-ac4a-7cef-17e408faac1d@oracle.com> <60bf6651-517e-0dca-7303-2e945c079fdf@oracle.com> Message-ID: <3d989922-1c84-7f31-3bd7-563fb43d759c@oracle.com> On 2/18/19 1:50 AM, Severin Gehwolf wrote: > On Fri, 2019-02-15 at 23:27 -0800, Mandy Chung wrote: >> On 2/15/19 8:12 AM, Severin Gehwolf wrote: >>> Thanks for the review! I've remove the @author tag: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218913/03/webrev/ >> >> Looks good. As Alan said, this needs a CSR to document the new plugin >> command-line option. > > Thanks. CSR has been filed here: > https://bugs.openjdk.java.net/browse/JDK-8219207 Reviewed. Mandy From sgehwolf at redhat.com Fri Feb 22 15:29:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Feb 2019 16:29:22 +0100 Subject: [PING?] RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: Mandy, Alan, any more thoughts on this? Thanks, Severin On Fri, 2019-02-15 at 18:01 +0100, Severin Gehwolf wrote: > Hi Alan, Mandy, > > Here is the next round of this change: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ > > It now also has tests which don't require objcopy to be present on test > machines as well as being integrated with --strip-debug (once JDK- > 8218913 is pushed). --list-plugins help output for --strip-native- > debug-symbols now reads: > > ----->8------------------------- > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > omit-debuginfo: Do not keep debug info files. Defaults to true. > keep-debuginfo[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=omit-debuginfo > --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy > ----->8------------------------- > > Testing: jdk.jlink tests jdk/submit (ongoing), added tests: > DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest > > Note: IntegrationTest needed a heap size bump as this now runs > StripNativeDebugSymbolsPluginTest on some systems. Especially with > --with-native-debug-symbols=internal builds this can eat some > memory. > > Please let me know what you think. > > Thanks, > Severin > > On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > > --strip-native-debug-symbols no-keep-debuginfo > > > --strip-native-debug-symbols strip-debuginfo > > > --strip-native-debug-symbols remove-debuginfo > > > > > > It would avoid using negation. > > > > What about 'omit', i.e. > > > > --strip-native-debug-symbols omit-debuginfo > > --strip-native-debug-symbols keep-debuginfo= > > > > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > > strip-java-debug-symbols be acceptable? My thinking is that it would > > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > > > --strip-native-debug-symbols is okay. > > > > Having a second thought, javac -g and gcc -g both say "debugging > > information". I think we could go with: > > > > --strip-java-debug-info > > --strip-native-debug-info omit-debuginfo > > --strip-native-debug-info keep-debuginfo= > > > > unless anyone thinks `-debug-symbols` is better? > > > > The options are getting pretty good now. > > > > Mandy From mandy.chung at oracle.com Fri Feb 22 15:58:41 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 Feb 2019 07:58:41 -0800 Subject: [PING?] RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: <0fb2141e-6b36-180c-0454-b490dacd4452@oracle.com> Hi Severin, I haven't had time to look at this yet. I'll do that early next week. Mandy On 2/22/19 7:29 AM, Severin Gehwolf wrote: > Mandy, Alan, any more thoughts on this? > > Thanks, > Severin > > On Fri, 2019-02-15 at 18:01 +0100, Severin Gehwolf wrote: >> Hi Alan, Mandy, >> >> Here is the next round of this change: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ >> >> It now also has tests which don't require objcopy to be present on test >> machines as well as being integrated with --strip-debug (once JDK- >> 8218913 is pushed). --list-plugins help output for --strip-native- >> debug-symbols now reads: >> >> ----->8------------------------- >> Plugin Name: strip-native-debug-symbols >> Option: --strip-native-debug-symbols= >> Description: Strip debug symbols from native libraries (if any). >> This plugin requires at least one option: >> objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. >> omit-debuginfo: Do not keep debug info files. Defaults to true. >> keep-debuginfo[=]: Keep debug info files in .. >> Defaults to .debuginfo >> Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy >> --strip-native-debug-symbols=omit-debuginfo >> --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy >> ----->8------------------------- >> >> Testing: jdk.jlink tests jdk/submit (ongoing), added tests: >> DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest >> >> Note: IntegrationTest needed a heap size bump as this now runs >> StripNativeDebugSymbolsPluginTest on some systems. Especially with >> --with-native-debug-symbols=internal builds this can eat some >> memory. >> >> Please let me know what you think. >> >> Thanks, >> Severin >> >> On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: >>> On 2/13/19 1:04 AM, Severin Gehwolf wrote: >>>>> --strip-native-debug-symbols no-keep-debuginfo >>>> --strip-native-debug-symbols strip-debuginfo >>>> --strip-native-debug-symbols remove-debuginfo >>>> >>>> It would avoid using negation. >>> >>> What about 'omit', i.e. >>> >>> --strip-native-debug-symbols omit-debuginfo >>> --strip-native-debug-symbols keep-debuginfo= >>> >>>> Sure. I've filed JDK-8218913 for doing this first. Would a name of -- >>>> strip-java-debug-symbols be acceptable? My thinking is that it would >>>> have nice symmetry with --strip-native-debug-symbols. Thoughts? >>> >>> --strip-native-debug-symbols is okay. >>> >>> Having a second thought, javac -g and gcc -g both say "debugging >>> information". I think we could go with: >>> >>> --strip-java-debug-info >>> --strip-native-debug-info omit-debuginfo >>> --strip-native-debug-info keep-debuginfo= >>> >>> unless anyone thinks `-debug-symbols` is better? >>> >>> The options are getting pretty good now. >>> >>> Mandy > From Alan.Bateman at oracle.com Mon Feb 25 10:49:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Feb 2019 10:49:29 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> Message-ID: <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> On 15/02/2019 17:01, Severin Gehwolf wrote: > : > > ----->8------------------------- > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > omit-debuginfo: Do not keep debug info files. Defaults to true. > keep-debuginfo[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=omit-debuginfo > --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy > ----->8------------------------- > I haven't had time let to look at the webrev yet but on the CLI options then I think the above approach looks quite good. There are 3 existing plugins that expose --exclude-XXX options so you might want consider renaming "omit" to "exclude" to be consistent. Another suggestion is consider adding the "-files" suffix to the debuginfo values so that it's clear to anyone reading a script that it's about exclude or keeping debuginfo files, e.g. --strip-native-debug-symbols exclude-debuginfo-files --strip-native-debug-symbols keep-debuginfo-files=pdb -Alan From sgehwolf at redhat.com Mon Feb 25 20:26:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Feb 2019 21:26:49 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: On Mon, 2019-02-25 at 10:49 +0000, Alan Bateman wrote: > On 15/02/2019 17:01, Severin Gehwolf wrote: > > : > > > > ----->8------------------------- > > Plugin Name: strip-native-debug-symbols > > Option: --strip-native-debug-symbols= > > Description: Strip debug symbols from native libraries (if any). > > This plugin requires at least one option: > > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > > omit-debuginfo: Do not keep debug info files. Defaults to true. > > keep-debuginfo[=]: Keep debug info files in .. > > Defaults to .debuginfo > > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > > --strip-native-debug-symbols=omit-debuginfo > > --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy > > ----->8------------------------- > > > I haven't had time let to look at the webrev yet but on the CLI options > then I think the above approach looks quite good. There are 3 existing > plugins that expose --exclude-XXX options so you might want consider > renaming "omit" to "exclude" to be consistent. Another suggestion is > consider adding the "-files" suffix to the debuginfo values so that it's > clear to anyone reading a script that it's about exclude or keeping > debuginfo files, e.g. > > --strip-native-debug-symbols exclude-debuginfo-files > --strip-native-debug-symbols keep-debuginfo-files=pdb Sure. This works for me. I'll update the code and the CSR shortly. Thanks, Severin From mandy.chung at oracle.com Mon Feb 25 22:26:52 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Feb 2019 14:26:52 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: On 2/25/19 2:49 AM, Alan Bateman wrote: > On 15/02/2019 17:01, Severin Gehwolf wrote: >> : >> >> ----->8------------------------- >> Plugin Name: strip-native-debug-symbols >> Option: --strip-native-debug-symbols= >> Description: Strip debug symbols from native libraries (if any). >> ? This plugin requires at least one option: >> ??? objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. >> ??? omit-debuginfo: Do not keep debug info files. Defaults to true. >> ??? keep-debuginfo[=]: Keep debug info files in .. >> ??????????????????????????? Defaults to .debuginfo >> ? Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy >> ??????????? --strip-native-debug-symbols=omit-debuginfo >> ??????????? --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy >> ----->8------------------------- >> > I haven't had time let to look at the webrev yet but on the CLI options > then I think the above approach looks quite good. There are 3 existing > plugins that expose --exclude-XXX options so you might want consider > renaming "omit" to "exclude" to be consistent. Another suggestion is > consider adding the "-files" suffix to the debuginfo values so that it's > clear to anyone reading a script that it's about exclude or keeping > debuginfo files, e.g. > > --strip-native-debug-symbols exclude-debuginfo-files > --strip-native-debug-symbols keep-debuginfo-files=pdb Adding the "-files" suffix sounds good to me. I'm okay with omit-debuginfo-files or exclude-debuginfo-files. One comment though this is a plugin option name rather than a plugin name (so not necessarily to consider consistency with plugin names). Mandy From Alan.Bateman at oracle.com Tue Feb 26 09:46:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2019 09:46:27 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: On 25/02/2019 22:26, Mandy Chung wrote: > > Adding the "-files" suffix sounds good to me.? I'm okay > with omit-debuginfo-files or exclude-debuginfo-files. > > One comment though this is a plugin option name rather than > a plugin name (so not necessarily to consider consistency > with plugin names). > True although one of those existing plugin options is --exclude-files which which can be used to do the equivalent of exclude-debuginfo-files. So I think it's mildly better to have these consistent if we can. -Alan. From sgehwolf at redhat.com Tue Feb 26 11:01:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Feb 2019 12:01:31 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: On Tue, 2019-02-26 at 09:46 +0000, Alan Bateman wrote: > On 25/02/2019 22:26, Mandy Chung wrote: > > Adding the "-files" suffix sounds good to me. I'm okay > > with omit-debuginfo-files or exclude-debuginfo-files. > > > > One comment though this is a plugin option name rather than > > a plugin name (so not necessarily to consider consistency > > with plugin names). > > > True although one of those existing plugin options is --exclude-files > which which can be used to do the equivalent of exclude-debuginfo-files. > So I think it's mildly better to have these consistent if we can. --list-plugins output for --strip-native-debug-symbols: Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any). This plugin requires at least one option: objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. exclude-debuginfo-files: Omit debug info files. Defaults to true. keep-debuginfo-files[=]: Keep debug info files in .. Defaults to .debuginfo Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy --strip-native-debug-symbols=exclude-debuginfo-files --strip-native-debug-symbols keep-debuginfo-files:objcopy=objcopy Latest webrev which implements this: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/08/webrev/ CSR for the new jlink option: https://bugs.openjdk.java.net/browse/JDK-8219257 Thanks, Severin From Alan.Bateman at oracle.com Tue Feb 26 17:59:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2019 17:59:28 +0000 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: On 26/02/2019 11:01, Severin Gehwolf wrote: > : > --list-plugins output for --strip-native-debug-symbols: > > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > exclude-debuginfo-files: Omit debug info files. Defaults to true. > keep-debuginfo-files[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=exclude-debuginfo-files > --strip-native-debug-symbols keep-debuginfo-files:objcopy=objcopy > > > Latest webrev which implements this: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/08/webrev/ > > CSR for the new jlink option: > https://bugs.openjdk.java.net/browse/JDK-8219257 I don't have time right now to study the webrev but I think the proposal (and CSR) looks okay. The only thing is that it's bit awkward that each of the possible values to the option are optionally but at least one is required. Once jlink is updated to allow for the value to be optional then I assume this wart can go away. -Alan From tjwats at gmail.com Tue Feb 26 19:38:13 2019 From: tjwats at gmail.com (Thomas Watson) Date: Tue, 26 Feb 2019 13:38:13 -0600 Subject: ModuleLayer.defineModules function clf must be stateful? Message-ID: I noticed that the clf function passed to ModuleLayer.defineModules(Configuration, List, Function) is called at least twice for every module name contained in the new ModuleLayer. Once for the call to java.lang.ModuleLayer.checkForDuplicatePkgs(Configuration, Function) and once for the call to java.lang.Module.defineModules(Configuration, Function, ModuleLayer) In my case I was returning a new ClassLoader object each call to my clf function. But I noticed that I was creating twice as many class loaders than needed for the ModuleLayer. Ultimately it looks like the checkForDuplciatePkgs method throws away the created ClassLoader and then the second call to my clf in defineModules gets the actual class loader that will be used by the module. My question: is this expected? Is my function expected to hold state and return the same class loader object each time it is called for a specific module name? Tom From Alan.Bateman at oracle.com Tue Feb 26 20:47:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Feb 2019 20:47:41 +0000 Subject: ModuleLayer.defineModules function clf must be stateful? In-Reply-To: References: Message-ID: On 26/02/2019 19:38, Thomas Watson wrote: > I noticed that the clf function passed to > ModuleLayer.defineModules(Configuration, List, > Function) is called at least twice for every module > name contained in the new ModuleLayer. Once for the call > to java.lang.ModuleLayer.checkForDuplicatePkgs(Configuration, > Function) and once for the call > to java.lang.Module.defineModules(Configuration, Function ClassLoader>, ModuleLayer) > > In my case I was returning a new ClassLoader object each call to my clf > function. But I noticed that I was creating twice as many class loaders > than needed for the ModuleLayer. Ultimately it looks like the > checkForDuplciatePkgs method throws away the created ClassLoader and then > the second call to my clf in defineModules gets the actual class loader > that will be used by the module. My question: is this expected? Is my > function expected to hold state and return the same class loader object > each time it is called for a specific module name? The original intention is that it be a pure function but the spec isn't clear on that. In addition, the implementation can't trust any of the parameters so it will have to memorize the class loader which amounts to calling the mapping function once per module. Can you submit a bug for this? -Alan From mandy.chung at oracle.com Tue Feb 26 21:35:30 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Feb 2019 13:35:30 -0800 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> Message-ID: <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> Hi Severin, This is my initial set of comments. On 2/26/19 3:01 AM, Severin Gehwolf wrote: > --list-plugins output for --strip-native-debug-symbols: > > Plugin Name: strip-native-debug-symbols > Option: --strip-native-debug-symbols= > Description: Strip debug symbols from native libraries (if any). > This plugin requires at least one option: > objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. > exclude-debuginfo-files: Omit debug info files. Defaults to true. s/Omit/Exclude/ > keep-debuginfo-files[=]: Keep debug info files in .. > Defaults to .debuginfo > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy This is a little awkward that this defaults to exclude-debuginfo-files.? As described above, I would expect "exclude-debuginfo-files" or "keep-debuginfo-files" must be specified.? It means that the command would be: ??? --strip-native-debug-symbols exclude-debuginfo-files:objcopy=/usr/bin/objcopy > --strip-native-debug-symbols=exclude-debuginfo-files > --strip-native-debug-symbols keep-debuginfo-files:objcopy=objcopy > What is the expected behavior when jlink --strip-debug --strip-native-debug-symbols keep-debuginfo-files is specified? Should it be accepted?? This should be specified in the CSR. > Latest webrev which implements this: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/08/webrev/ > DefaultStripDebugPlugin.java I still think that conceptually it's more straight-forward to treat --strip-debug option to imply as if --strip-java-debug-attributes and --strip-native-debug-symbols option, if available and not specified, were specified on the command line.? These plugins will be invoked accordingly rather than an explicit invocation of these 2 plugins.?? But we don't have such precedence to follow.?? W.r.t. your current implementation: I think this can be simplfied to keep Optional field and replace DefaultNativePluginFactory and NativePluginFactory with a simple static method to return Optional.ofNullable(...). ? 47???? private static final String OMIT_DEBUGINFO = "exclude-debuginfo-files"; Nit: rename OMIT_ to EXCLUDE_ to match the name ? 77???????????? Map stripNativeConfig = Map.of( drop the diamond operation. StripNativeDebugSymbolsPlugin.java ? 56???? public static final String NAME = "strip-native-debug-symbols"; Does this need to be public?? Should it be private static field? ?101???????????? if (resource.type() == ResourcePoolEntry.Type.NATIVE_LIB || ?102???????????????? resource.type() == ResourcePoolEntry.Type.NATIVE_CMD) { ?103???????????????? String moduleName = resource.moduleName(); ?104???????????????? if (resource.path().endsWith(SHARED_LIBS_EXT) || ?105???????????????????? resource.path().startsWith("/" + moduleName + "/bin")) { Alternatively: ?if ((resource.type() == ResourcePoolEntry.Type.NATIVE_LIB ??? ??? && resource.path().endsWith(SHARED_LIBS_EXT)) || ??? resource.type() == ResourcePoolEntry.Type.NATIVE_CMD) If --strip-native-commands is specified, this may want to skip processing NATIVE_CMD?? Alternatively it should ensure -strip-native-commands is invoked before --strip-native-debug-symbols; otherwise, debuginfo files might have left behind if keep-debuginfo-files is specified while the native commands are stripped later. doConfigure compares if arg matches one of the expected argument names.? I think it does not report if any invalid argument? Looks like it also accepts --strip-native-debug-symbols=exclude-debuginfo-files=abc:keep-debuginfo-files=cde. This might be a jlink plugin parsing bug? createDebugSymbolsFile, addGnuDebugLink and stripBinary - if the command fails, should the plugin fail instead? you currently silently ignore any error. ObjCopyCmdBuilder.build(String objCopy) can be changed to ObjCopyCmdBuilder.build(String objCopy, String... opts) to build the entire command line in one go. Nit: StrippedDebugInfoBinary can be made immutable.? It might be cleaner to refactor the createDebugSymbolsFile, addGnuDebugLink and stripBinary methods in a builder class to build a StrippedDebugInfoBinary for a given ResourcePoolEntry. I suggest to place the tests under test/jdk/tools/jlink/plugins/StripNativeDebugSymbolsPlugin/ which I think jlink tests are organized with plugin class name rather than plugin option name. Mandy From sgehwolf at redhat.com Thu Feb 28 16:35:53 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Feb 2019 17:35:53 +0100 Subject: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries In-Reply-To: <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> References: <93ca9d6879668509769b58869c3475d728ab5ec2.camel@redhat.com> <6cc30b09-a4dd-bc01-3985-f681270572f5@oracle.com> <653b6916fd06dad691c6329ef17ff0ec141bdb8c.camel@redhat.com> <42722379-3d1d-3903-f0e2-97773872984b@oracle.com> <3bf9d0cc-23b0-d4fb-7432-ea6f4998ba6a@oracle.com> Message-ID: <1f27a257f3e164080a0eafa1db99cd68a83e2e15.camel@redhat.com> Hi Mandy, Thanks for the review! I'll update the webrev ASAP and will get back to you once ready. Thanks, Severin On Tue, 2019-02-26 at 13:35 -0800, Mandy Chung wrote: > Hi Severin, > > This is my initial set of comments. > > On 2/26/19 3:01 AM, Severin Gehwolf wrote: > > --list-plugins output for --strip-native-debug-symbols: > > > > Plugin Name: strip-native-debug-symbols > > Option: --strip-native-debug-symbols= > debuginfo-files> > > Description: Strip debug symbols from native libraries (if any). > > This plugin requires at least one option: > > objcopy: The path to the objcopy binary. Defaults to objcopy in > > PATH. > > exclude-debuginfo-files: Omit debug info files. Defaults to > > true. > > s/Omit/Exclude/ > > keep-debuginfo-files[=]: Keep debug info files in > > .. > > Defaults to .debuginfo > > Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy > > This is a little awkward that this defaults to exclude-debuginfo- > files. As described above, I would expect "exclude-debuginfo-files" > or "keep-debuginfo-files" must be specified. It means that the > command would be: > --strip-native-debug-symbols exclude-debuginfo- > files:objcopy=/usr/bin/objcopy > > --strip-native-debug-symbols=exclude-debuginfo-files > > --strip-native-debug-symbols keep-debuginfo- > > files:objcopy=objcopy > > > > What is the expected behavior when jlink --strip-debug --strip- > native-debug-symbols keep-debuginfo-files is specified? Should it > be accepted? This should be specified in the CSR. > > Latest webrev which implements this: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/08/webrev/ > > > > DefaultStripDebugPlugin.java > > I still think that conceptually it's more straight-forward to treat > --strip-debug option to imply as if --strip-java-debug-attributes and > --strip-native-debug-symbols option, if available and not specified, > were specified on the command line. These plugins will be invoked > accordingly rather than an explicit invocation of these 2 plugins. > But we don't have such precedence to follow. W.r.t. your current > implementation: > > I think this can be simplfied to keep Optional field and > replace > DefaultNativePluginFactory and NativePluginFactory with a simple > static > method to return Optional.ofNullable(...). > > 47 private static final String OMIT_DEBUGINFO = "exclude- > debuginfo-files"; > > Nit: rename OMIT_ to EXCLUDE_ to match the name > > 77 Map stripNativeConfig = Map. String>of( > > drop the diamond operation. > > StripNativeDebugSymbolsPlugin.java > > 56 public static final String NAME = "strip-native-debug- > symbols"; > > Does this need to be public? Should it be private static field? > > 101 if (resource.type() == > ResourcePoolEntry.Type.NATIVE_LIB || > 102 resource.type() == > ResourcePoolEntry.Type.NATIVE_CMD) { > 103 String moduleName = resource.moduleName(); > 104 if (resource.path().endsWith(SHARED_LIBS_EXT) || > 105 resource.path().startsWith("/" + moduleName > + "/bin")) { > > > Alternatively: > > if ((resource.type() == ResourcePoolEntry.Type.NATIVE_LIB > && resource.path().endsWith(SHARED_LIBS_EXT)) || > resource.type() == ResourcePoolEntry.Type.NATIVE_CMD) > > > If --strip-native-commands is specified, this may want to skip > processing NATIVE_CMD? Alternatively it should ensure -strip-native- > commands is invoked before --strip-native-debug-symbols; otherwise, > debuginfo files might have left behind if keep-debuginfo-files is > specified while the native commands are stripped later. > > doConfigure compares if arg matches one of the expected argument > names. I think it does not report if any invalid argument? > > Looks like it also accepts --strip-native-debug-symbols=exclude- > debuginfo-files=abc:keep-debuginfo-files=cde. This might be a jlink > plugin parsing bug? > > createDebugSymbolsFile, addGnuDebugLink and stripBinary > > - if the command fails, should the plugin fail instead? you currently > silently ignore any error. > > ObjCopyCmdBuilder.build(String objCopy) can be changed to > ObjCopyCmdBuilder.build(String objCopy, String... opts) to build the > entire command line in one go. > > Nit: StrippedDebugInfoBinary can be made immutable. It might be > cleaner to refactor the createDebugSymbolsFile, addGnuDebugLink and > stripBinary methods in a builder class to build a > StrippedDebugInfoBinary for a given ResourcePoolEntry. > > I suggest to place the tests under > test/jdk/tools/jlink/plugins/StripNativeDebugSymbolsPlugin/ which I > think jlink tests are organized with plugin class name rather than > plugin option name. > > Mandy