RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries
sgehwolf at redhat.com
Tue Feb 12 19:52:36 UTC 2019
Hi Mandy, Alan,
Please find the proposal for CLI option of --strip-native-debug-symbols
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 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=<path-to-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:
[i] --strip-native-debug-symbols defaults
[ii] --strip-native-debug-symbols options:objcopy-cmd=<path/to/objcopycmd>
[iii] --strip-native-debug-symbols options:debuginfo-file-ext=<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:
Case [ii] would become:
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[=<ext>]
[b] --strip-native-debug-symbols objcopy=<path/to/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?
More information about the build-dev