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

[Mandy Chung]

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

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