Hi Magnus,
On 1/03/2018 10:48 AM, Magnus Ihse Bursie wrote:
We're doing a lot of weird compilation stuff for dtrace. With this
patch, most of the weirdness is removed. The remaining calls to $(CC) -E
has been changed to $(CPP) to clarify that we do not compile, we just
use the precompiler.
One of the changes I made was to actually split up the last and final
dtrace call into a separate preprocessing step. However, this uses the
solaris studio preprocessor instead of the ancient system preprocessor,
which has changed behavior. A string like (&``_var) is now expanded to
(& ` ` _var), which is not accepted by dtrace. :-( I have worked around
this by adding the preprocessed output, without the spaces, in two
places. If anyone wants to dig deeper into dtrace script file syntax, or
C preprocessor magic, to avoid this, let me know... (I'll just state
that the "obvious" solution of sending -Xs to the preprocessor to get
old-style behavior does not work: this just makes the solaris studio
preprocessor call the ancient preprocessor in turn, and we've gained
nothing...)
Bug: https://bugs.openjdk.java.net/browse/JDK-8198862
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8198862-stop-doing-funky-dtrace-compilation-stuff/webrev.01
Why did you rename generateJvmOffsetsMain.c to
generateJvmOffsetsMain.cpp? It isn't a C++ program, it's just a C program.
I agree the logic is quite confusing. I think this build logic was
victim of the CPP_FLAGS (meaning C preprocessor) to CXX_FLAGS (meaning
C++ flags) renaming. But this is a trivial C program and should require
trivial C compiler flags. I don't see it should be being built with all
the JVM_CFLAGS. The latter may be harmless but it seems wrong to lump
this in together with other things.
make/hotspot/lib/CompileDtracePreJvm.gmk
! # Since we cannot generated JvmOffsets.cpp as part of the gensrc step,
Comment doesn't read right.
Thanks,
David
/Magnus
