From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-03-27 02:25:32
Khassapov, Alex wrote:
> Hi Jurco,
> DTrace is a dynamic tracing facility that is built into Solaris and can be used to examine the
> behavior of both user programs and of the operating system itself.
> In the example below it modifies .o files according to myserv.d dtrace script (which tells dtrace
> which functions we are interested in), it inserts hooks into the function calls of interest, but
> the hooks are actually implemented in the generated myserv.o object file which is also linked into
> the resulting executable.
How weird. As long as they modify object files in place, I don't really understand why they
cannot instrument the entire produced binary.
> So just a generator won't be sufficient. dtrace call should be inserted in between compilation
> and linking steps and the output of dtrace (.o file) linked back into the calling project.
Of course a generator will be sufficient.
> It's really easy to achive in Automake as I showed in my previous post (2008-03-25 02:55:11 GMT),
> but I've got no idea how to do it in bjam!
The key to implement something using Boost.Build is to accurately model the tools you have.
You have this dtrace thing, so you get to build a new generator corresponding to dtrace tool.
Second, you have to modify how executable is build, so you create a new generator for that,
which relay to standard build process for executable by calling generators.construct.
I attach an example project, which does that, and produces output like this:
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -c -o "bin/gcc-4.1.3/debug/a.o" "a.cpp"
dtrace -o bin/gcc-4.1.3/debug/a_dtrace.o bin/gcc-4.1.3/debug/a.o
"g++" -o "bin/gcc-4.1.3/debug/a" -Wl,--start-group "bin/gcc-4.1.3/debug/a.o" "bin/gcc-4.1.3/debug/a_dtrace.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g
Of course, you'd have to adjust dtrace invocation to taste, and probably fix something else,
but it appears like it's both doable, and not very hard, either.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk