> Should we expect the patch to build on Mac OS X? OOC, do you know if the
> format of the dtrace-generated probes.o is documented someplace?
I have heard that dtrace does work a bit differently on macos but I
would need to investigate. The probes.o file is different for systemtap
and dtrace. For systemtap it is simply an objectfile with variable
definitions for the probe semaphores (to test if a probe is enabled;
mostly used by interpreters like java). For dtrace, hmm been a while
since I looked at it. dtrace uses an interpreter that runs in the
kernel, I think probes.o contains the bytecodes for the probes.
> Shouldn't the build just continue on without dtrace configured in?
The model I followed, mysql/postgres work this way but I did make the
failure fatal.
> All of this decoding should be offloaded to the event handler,
trace.c is now much simpler. The trace display logic is now moved to
pmcd.std, the systemtap probe handler.
> Do we really need it, given its in the !dtrace path?
This is now eliminated in favor of having configure create config.h
which indicates the presence or absence of --enable-dtrace.
> could you update the RPM build dependencies in the
> build/rpm spec files as well?
Still need to do this.
* configure.in: Add --enable-dtrace and AC_CONFIG_HEADERS.
* builddefs.in: Add DTRACE and enable_dtrace
* GNUmakefile: Add probes.h and probes.o
* libpcp_pmcd/src/trace.c: Include config.h and probes.h.
Add trace_mask and static probe landing point to pmcd_trace
* (agent.c, client.c, config.c, dofetch.c, dopdus.c, dostore.c,
pmcd.c, pmcd.h): New pmcd_trace calling sequence.
* probes.d: New. systemtap static probe definition file.
* probes_nodtrace.h: For --disable-dtrace case.
* pmcd.stp: New. Systemtap pmcd probes file. Mimics pmcd_dump_trace.
,gitdiff0
Description: Text document
|