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

[Severin Gehwolf]

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

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=<path/to/fake-objcopy' option in that
case. 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.

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