RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries

[Severin Gehwolf]

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

--strip-native-debug-symbols keep-debuginfo
--strip-native-debug-symbols keep-debuginfo=<ext>

Case [ii] would become:

--strip-native-debug-symbols objcopy=<path/to/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[=<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?

Thanks,
Severin