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

[Mandy Chung]

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=<defaults|options[:objcopy-cmd=<path/to/objcopycmd>][:debuginfo-file-ext=<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.<ext> 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=<debug-file-ext>,][objcopy-path=<path-of-objcopy>]

By default, `--strip-native-debug` will strip native debug symbols
and don't keep debug symbols.

keep-debug=<debug-file-ext> creates the debug symbols file.
<debug-file-ext> 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