Improve DTrace probe generation with non-default compiler #11643
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With DTrace support enabled during ./configure, our custom Autoconf macro PHP_INIT_DTRACE creates make rules to generate header and object files using dtrace utility. SystemTap† implementation of dtrace relies on other utilities to provide header preprocessing and final object file compilation. These utilities are configured by common environment variables with common defaults:‡ * preprocessor from CPP defaults to “cpp” * compiler from CC defaults to “gcc” * compiler arguments can be expanded with CFLAGS This has been in SystemTap since version 1.5 released on 2011-05-23. We have been setting CFLAGS for dtrace since 717b367 released in versions 5.4.20 and 5.5.4 on 2013-09-18. This change fixed build against SystemTap. It fixes majority of cases since practically all free Linux distributions use SystemTap for DTrace-like dynamic tracing and practically all of them use GCC or compatible compiler suite. However, this becomes an issue when cross-compiling using GCC because utility names contain target triplets. Autoconf already handles cross-compilation well —setting correct CC and CPP make macros (variables). Therefore, we simply set CC and CPP environment variables using respective macros when executing dtrace. Although SystemTap dtrace does not always use CC nor CPP, we set it every time. SystemTap documentation does not talk about this at all¶, so it is safer to always set it. We also follow how we set CFLAGS every time in the past. Original (or ported) DTrace mainly used on Oracle Linux, Solaris and macOS ignores these and does not support cross compilation.§ † Well-known dynamic tracing infrastructure for Linux compatible with statically-defined tracing from DTrace. ‡ https://sourceware.org/git/?p=systemtap.git;a=blob;f=dtrace.in;h=73a6f22e2de072773c692e3fea05c4b8cf814e43;hb=ebb424eee5599fcc131901c0d82d0bfc0d2f57ab ¶ https://sourceware.org/systemtap/man/dtrace.1.html § https://docs.oracle.com/cd/E88353_01/html/E72487/dtrace-8.html
|
Thank you @f4z4on for this patch. This is ok to merge, yes. I'm only wondering if we should at the same time enable this also for the OCI8 extension (OCI8 extension is otherwise a bit special and @cjbj usually needs to add this because the extension sources are on two places): diff --git a/ext/oci8/config.m4 b/ext/oci8/config.m4
index 714c655be4..883e272fb1 100644
--- a/ext/oci8/config.m4
+++ b/ext/oci8/config.m4
@@ -124,7 +124,7 @@ dnl overwritten (Bug 61268).
PHP_EXT_SRCDIR([oci8])/$ac_provsrc:;
$ac_bdir[$]ac_hdrobj: $ac_srcdir[$]ac_provsrc
- CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHPOCI_,DTRACE_,g' \$[]@.bak > \$[]@
+ CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@.bak && \$(SED) -e 's,PHPOCI_,DTRACE_,g' \$[]@.bak > \$[]@
\$(OCI8_DTRACE_OBJS): $ac_bdir[$]ac_hdrobj
@@ -145,12 +145,12 @@ EOF
$ac_bdir[$]ac_provsrc.lo: \$(OCI8_DTRACE_OBJS)
echo "[#] Generated by Makefile for libtool" > \$[]@
@test -d "$dtrace_lib_dir" || mkdir $dtrace_lib_dir
- if CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
+ if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $dtrace_d_obj -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_lib_objs 2> /dev/null && test -f "$dtrace_d_obj"; then [\\]
echo "pic_object=['].libs/$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "pic_object='none'" >> \$[]@ [;\\]
fi
- if CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $ac_srcdir[$]ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
+ if CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o $ac_bdir[$]ac_provsrc.o -s $ac_srcdir[$]ac_provsrc $dtrace_nolib_objs 2> /dev/null && test -f "$ac_bdir[$]ac_provsrc.o"; then [\\]
echo "non_pic_object=[']$dtrace_prov_name[']" >> \$[]@ [;\\]
else [\\]
echo "non_pic_object='none'" >> \$[]@ [;\\]
@@ -162,7 +162,7 @@ EOF
AC_MSG_WARN([OCI8 extension: OCI8 DTrace support is not confirmed on this platform])
cat>>Makefile.objects<<EOF
$ac_bdir[$]ac_provsrc.o: \$(OCI8_DTRACE_OBJS)
- CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_objs
+ CPP="\$(CPP)" CC="\$(CC)" CFLAGS="\$(CFLAGS_CLEAN)" dtrace -G -o \$[]@ -s $ac_srcdir[$]ac_provsrc $dtrace_oci8_objs
EOF
;; |
|
This was referenced Aug 2, 2023
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C precessor the user chose or configure detected (CPP). 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Therefore, intentional code seems like the best next option. Please note, all of this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). The same is true about -C option which is specific to SystemTap which is also ignored by other DTrace implementations. † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all dtrace invocation in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope this makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. SystemTap dtrace expects C language preprocessor because pragmas in D programming language used by DTrace are the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors (most notably Clang) recognize this option too. Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C processor the user chose or configure detected (CPP). 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Therefore, intentional code seems like the best next option. Please note, all of this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). The same is true about -C option which is specific to SystemTap which is also ignored by other DTrace implementations. † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 2, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on C compiler and preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all dtrace invocation in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope this makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. SystemTap dtrace expects C language preprocessor because pragmas in D programming language used by DTrace are the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors (most notably Clang) recognize this option too. Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 4, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on both external C compiler and external preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags from CFLAGS_CLEAN macro have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We have modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). External C preprocessor use via the -C option is actually common to dtrace implementations other than SystemTap even for actions other than generating header files. However, customization of C preprocessor differs widely between SystemTap and the rest of DTrace ecosystem (for example, no other implementation uses environment variables). Before, we fix the issue itself, we stop setting all these environment variables when invoking dtrace. We set only those necessary for particular action: 1. When generating headers file (-h option) with the help of C preprocessor (-C option), we pass the C processor the user chose or configure detected (CPP). No CC nor CFLAGS environment variables. 2. When generating object files with probes (-G option), we pass the C compiler and its flags the user chose or configure detected (CC and CFLAGS). No CPP environment variable. We hope this code style inconsistency in dtrace invocation will actually be useful in that it allows simpler fix to the issue we are experiencing when building PHP with DTrace enabled with SystemTap. We believe this also makes clearer the fact this is a strange area of PHP build process and vendor-independent invocation of dtrace is tricky. Hopefully, if there is some future need to change how we define and build statically-defined traces, people will notice differences between uses for dtrace. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 8 lines of make commands… Moreover, such macros probably belong to a project like GNU Autoconf rather than to PHP. Therefore, intentional code seems like the best next option. Please note, all this is specific to SystemTap which is itself available only on Linux. Oracle DTrace, Open DTrace or their forks do not use environment variables (they ignore them). † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 4, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† SystemTap, unlike Oracle DTrace, Open DTrace or their forks, relies on both external C compiler and external preprocessor. We have recently aligned both of these with compiler and preprocessor we use to build regular C source code (see phpGH-11643).‡ We set CPP environment variable to the value of our CPP macro which defaults to C preprocessor detected by configure script. Similarly, we set CC environment variable to the value of our CC macro which defaults to C compiler detected by configure script. C compiler flags from CFLAGS_CLEAN macro have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all dtrace invocations in the same way to make it look consistent. However, SystemTap dtrace needs C preprocessor only when it generates header files (-h option) with preprocessing (-C option). Similarly, it needs C compiler only when it generates object files with probe definitions (-G option). External C preprocessor use via the -C option is actually common to dtrace implementations other than SystemTap even for actions other than generating header files. However, customization of C preprocessor differs widely between SystemTap and the rest of DTrace ecosystem (for example, no other implementation uses environment variables). Therefore, we have recently stopped setting all these environment variables when invoking dtrace. We set only what is necessary for particular action. We hope it makes this fix simpler and clearer without introducing additional complexity to our build system. The cause of our issue is the fact that GCC preprocessor, when invoked via “gcc” binary, detects the language for preprocessing from source file extensions. Because DTrace probes and providers for statically-defined tracing are in files with “.d” extension, GCC detection fails because it probably thinks it is processing proper D programing language source code (somewhat different from what DTrace uses) which has no C-style preprocessing macros. People have noticed, because configure script on systems with GCC sets CPP make macro to “gcc -E”. Therefore practically everyone, who does not override C preprocessor to “cpp”, who is building PHP with DTrace enabled on Linux with SystemTap, experiences this issue. We force C language when passing C preprocessor as set by the user or detected by the configure script. D programs for DTrace commonly use C language preprocessor. This includes statically-defined tracing probes which can contain the same #pragma directives known from C and similar languages. We use -x option from GCC to force C. Other compilers suites and their preprocessors may recognize this option too (most notably Clang). Many probably do not. However, this issue is specific to SystemTap, which is itself specific to Linux and has to be build using the same compiler as Linux kernel, which only supports building using GCC-compatible compilers. This limitation of using only GCC-compatible compiler suite does not apply to applications with statically-defined tracing. We can definitely imagine someone building PHP with DTrace enabled using SystemTap and wanting to use compiler suite or preprocessor which is different from what they used to build SystemTap itself or their Linux kernel and which does not recognize the -x option. However, we do not think it is reasonable to accommodate for such use case. Properly solving this would require implementing non-trivial m4 macros, which is probably not warranted given this affects 2 lines of make commands… Moreover, such macros probably belong to a project like GNU Autoconf rather than to PHP. This has no effect on Oracle DTrace, Open DTrace or any of their forks because they do not allow customization of preprocessor nor compiler via environment variables. They simply ignore CPP, CC, and CFLAGS environment variables, so it does not matter what values we set there. Fixes phpGH-11847 † php#11847 ‡ php#11643
f4z4on
added a commit
to f4z4on/php-src
that referenced
this pull request
Aug 30, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see phpGH-11847).† The issue is caused by inappropriate use C preprocessor detected by GNU Autoconf in our “configure” script. C preprocessor configuration found by AC_PROG_CPP macro is portable only to run on files with “.c” extension.‡ However, statically-defined tracing is described by D programs with “.d” extension which causes the issue. We experience this even on typical Linux distribution with GNU Compiler Collection (GCC) unless we override the defaults detected by our “configure” script. Many major Linux distributions use SystemTap to provide “dtrace” utility. It relies on both external C preprocessor and external C compiler. C preprocessor can be customized via CPP environment variable. Similarly, C compiler can be customized via CC environment variable. It also allows customization of C compiler flags via CFLAGS environment variable. We have recently aligned both CPP and CC environment variable with C preprocessor and C compiler we use to build regular C source code as provided by our “configure” script (see phpGH-11643).* We wanted to allow cross-compilation on Linux for which this was the only blocker. C compiler flags from CFLAGS_CLEAN macro have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all “dtrace” invocations in the same way to make it look consistent. However, only the C compiler (CC environment variable) is necessary to for cross-compilation. There have never been any reported issue with the C preprocessor. We acknowledge it would be great to allow C preprocessor customization as well. However, the implementation would require a lot of effort to do correctly given the limitations of AC_PROG_CPP macro from GNU Autoconf. This would be further complicated by the fact that all DTrace implementations, not just SystemTap, allow C preprocessor customization but Oracle DTrace, Open DTrace, and their forks do it differently. Nevertheless, they all default to “cpp” utility and they all have or had been working fine. Therefore, we believe simply removing CPP stabilizes “dtrace” invocation on Linux systems with SystemTap and aligns it with other system configurations on other platforms, until someone comes with complete solution with custom “m4” and “make” macros, while our build system on Linux with SystemTap supports cross-compilation. Fixes phpGH-11847 † php#11847 ‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1 * php#11643
bukka
pushed a commit
that referenced
this pull request
Aug 30, 2023
We are experiencing an issue when building PHP with DTrace enabled with SystemTap (see GH-11847).† The issue is caused by inappropriate use C preprocessor detected by GNU Autoconf in our “configure” script. C preprocessor configuration found by AC_PROG_CPP macro is portable only to run on files with “.c” extension.‡ However, statically-defined tracing is described by D programs with “.d” extension which causes the issue. We experience this even on typical Linux distribution with GNU Compiler Collection (GCC) unless we override the defaults detected by our “configure” script. Many major Linux distributions use SystemTap to provide “dtrace” utility. It relies on both external C preprocessor and external C compiler. C preprocessor can be customized via CPP environment variable. Similarly, C compiler can be customized via CC environment variable. It also allows customization of C compiler flags via CFLAGS environment variable. We have recently aligned both CPP and CC environment variable with C preprocessor and C compiler we use to build regular C source code as provided by our “configure” script (see GH-11643).* We wanted to allow cross-compilation on Linux for which this was the only blocker. C compiler flags from CFLAGS_CLEAN macro have already been in place since versions 5.4.20 and 5.5.4 from 2013-09-18. We had modified all “dtrace” invocations in the same way to make it look consistent. However, only the C compiler (CC environment variable) is necessary to for cross-compilation. There have never been any reported issue with the C preprocessor. We acknowledge it would be great to allow C preprocessor customization as well. However, the implementation would require a lot of effort to do correctly given the limitations of AC_PROG_CPP macro from GNU Autoconf. This would be further complicated by the fact that all DTrace implementations, not just SystemTap, allow C preprocessor customization but Oracle DTrace, Open DTrace, and their forks do it differently. Nevertheless, they all default to “cpp” utility and they all have or had been working fine. Therefore, we believe simply removing CPP stabilizes “dtrace” invocation on Linux systems with SystemTap and aligns it with other system configurations on other platforms, until someone comes with complete solution with custom “m4” and “make” macros, while our build system on Linux with SystemTap supports cross-compilation. Fixes GH-11847 Closes GH-12083 † #11847 ‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1 * #11643
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With DTrace support enabled during
./configure, our custom Autoconf macroPHP_INIT_DTRACEcreates make rules to generate header and object files usingdtraceutility. SystemTap† implementation ofdtracerelies on other utilities to provide header preprocessing and final object file compilation. These utilities are configured by common environment variables with common defaults:CPPdefaults to"cpp"CCdefaults to"gcc"CFLAGSThis has been in SystemTap since version 1.5 released on 2011-05-23. We have been setting
CFLAGSfordtracesince 717b367 released in versions 5.4.20 and 5.5.4 on 2013-09-18. This change fixed build against SystemTap. It fixes majority of cases since practically all free Linux distributions use SystemTap for DTrace-like dynamic tracing and practically all of them use GCC or compatible compiler suite. However, this becomes an issue when cross-compiling using GCC because utility names contain target triplets. Autoconf already handles cross-compilation well—setting correctCCandCPPmake macros (variables).Therefore, we simply set
CCandCPPenvironment variables using respective macros when executingdtrace. Although SystemTapdtracedoes not always useCCnorCPP, we set it every time. SystemTap documentation does not talk about this at all, so it is safer to always set it. We also follow how we setCFLAGSevery time in the past.Original (or ported) DTrace mainly used on Oracle Linux, Solaris, macOS, FreeBSD or NetBSD ignores these and does not support cross compilation.
† Well-known dynamic tracing infrastructure for Linux compatible with statically-defined tracing from DTrace.