-
Bug
-
Resolution: Fixed
-
P3
-
9
-
b56
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8081902 | emb-9 | Erik Joelsson | P3 | Resolved | Fixed | b56 |
In JDK-8073021 I added support for compiling with gcov support for native code coverage. When trying to use this it was discovered that the file layout in the new symbols image need to exactly match the layout of the .gcno files in the build directory. Otherwise the runtime data files created by gcov will not match properly.
I originally tried to tidy up the layout in the symbols file into:
symbols/gcov/hotspot/{client,server}/*.gcno
symbols/gcov/jdk/$(module)/$(lib)/*.gcno
What we actually need is the (internal) layout of the intermediate build results:
symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno
symbols/gcov/support/native/$(module)/$(lib)/*.gcno
Our internal layout for intermediate build results is not something we want to export as an API, but in this case, the file layout just has to match the paths that get encoded into the binaries.
I originally tried to tidy up the layout in the symbols file into:
symbols/gcov/hotspot/{client,server}/*.gcno
symbols/gcov/jdk/$(module)/$(lib)/*.gcno
What we actually need is the (internal) layout of the intermediate build results:
symbols/gcov/hotspot/linux_amd64_compiler2/product/*.gcno
symbols/gcov/support/native/$(module)/$(lib)/*.gcno
Our internal layout for intermediate build results is not something we want to export as an API, but in this case, the file layout just has to match the paths that get encoded into the binaries.
- backported by
-
JDK-8081902 Change layout of gcov .gcno files in symbols image
-
- Resolved
-
- duplicates
-
JDK-8075737 Need to keep gcno files layout
-
- Closed
-