On 2020-08-28 14:50, Erik Joelsson wrote:
On 2020-08-28 00:51, Magnus Ihse Bursie wrote:
On 2020-08-27 23:26, Erik Joelsson wrote:
Hello Andrew,
We certainly appreciate contributions, but this patch as it
currently looks does not fit well with our current build system
model. I'm however not against adding a target for your usecase.
On a high level, just as Severin pointed out, the term "debug" is
used for the type configuration we are building (release vs debug).
For debug information we have instead chosen the term "symbols", so
the target should rather be called symbols-image. Now I realize we
already have that target, for something slightly different. I
introduced that a long time ago for gcov symbols, with the intention
of eventually move the main debug symbols into it too, but that
never happened. I think we can just make that change now and let the
symbols-image be what you are asking for (in addition to the gcov
files if those are enabled). This will be one step in the direction
of a bigger overhaul of the images that I want to do anyway.
On a lower level, in Main.gmk, all targets should be declared as
calls to the macro SetupTarget and in the correct section of the
file. In this case it would be around line 418 where the current
symbols-image is declared.
The new file DebugImage.gmk contains a lot of duplication of logic
already implemented in Images.gmk, which can quite easily be
extended to cover your usecase.
So all that said, this is how I would suggest to solve it:
http://cr.openjdk.java.net/~erikj/8252233/webrev.01/index.html
Erik,
I fully agree with you in your analysis on the proper way to solve
this. However, I have a hard time figuring out how the patch you
supplied will achieve that. :-) Maybe you can help me understand how
this would actually make the debug symbols be added to the symbol image?
Sure! In the already present "Debug symbols" section of Images.gmk, we
have a bunch of convoluted logic for finding all debugsymbols in the
respective modules_libs and modules_cmds dirs and generate rules for
copying them to the relevant images. This logic is already
parameterized to do the same job for the JRE and JDK images, so at the
bottom, there were already two calls to SetupCopyDebuginfo, one for
JDK and one for JRE. For these calls to work, there needs to be 2
variables defined specific to the image we are copying to. The list of
modules relevant for this image and the target directory,
ALL_$1_MODULES and $_IMAGE_DIR respectively. The patch adds the first
variable and the second was already defined as we already have symbols
image.
In Bundles.gmk, we generate the main JDK bundle by filtering out the
debugsymbols from the jdk image, then we generate the symbols image by
filtering just the debugsymbols from the jdk image, as well as adding
everything from the symbols image. The last part is basically only
done in case we built with gcov. Now with this patch, the symbols
image always contains the full set of debug symbols, so we would end
up with duplicate rules as the same files would be copied from two
different places. To fix this, I simply removed the JDK image as a
source of files for the symbols bundle.
I see. Thanks for the description! It sounds like your patch achieves
what was requested, and it looks good. Consider it reviewed by me. Let's
just hear that Andrew is satisfied as well.
The logic in Bundles.gmk is still unreasonably complex, and I hope to
fix this at some point, but I think it's out of scope for this change.
What I would like to do is change Images.gmk to generate a pure
symbols image (basically done with this patch) and a pure JDK image
containing exactly what should go into the bundle, then also
(optionally) a 3rd image that looks like our current JDK image with
the former two combined which is convenient for development use in
local builds.
Yes, that sounds much better.
/Magnus
/Erik
/Magnus
With this change, building the symbols image is part of the top
level product-images target (but separate from the more specific
jdk-image target). In Bundles.gmk, building the jdk bundles tar.gz
gets slightly simpler as the files can be found directly in the
symbols image.
I still need to test this properly on all platforms.
/Erik
On 2020-08-27 08:55, Andrew Leonard wrote:
Hi,
Please may I request a sponsor and review for this build
enhancement to
provide a pure debug "image", for those developers that want to
accompany
a straight jdk image with a debug-image when needed:
https://bugs.openjdk.java.net/browse/JDK-8252233
webrev: http://cr.openjdk.java.net/~aleonard/8252233/webrev.00/
We have been providing this as part of the openj9 builds at
AdoptOpenJDK
for a while now, and would like to contribute it upstream to openjdk.
Thanks
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: [email protected]
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with
number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
