[darwinbuild] some darwintrace ideas
Shantonu Sen
ssen at opendarwin.org
Thu Jul 7 17:57:06 PDT 2005
darwinbuild currently uses DYLD_INSERT_LIBRARIES/
DYLD_FORCE_FLAT_NAMESPACE with the "darwintrace.dylib" to log open(2)
and execve(2) system calls, for use in dependency analysis. This is
great for determining *what* is used during a project build, but not
"how" or "why" or "when"
Some experimental ideas I'm planning on taking a look at:
1) Full logging of execve(2) arguments
2) shell-escaping the execve(2) arguments so you can copy-paste
compiler invocations and such.
3) build a shell script to replay a build, to the extent that this is
possible with shell commands. During a build, there is some
computation/processing that would not be captured here.
4) synthesize shell commands for some system calls, like mkdir(2)
5) translating volfs paths to normal paths, for better logging of
Carbon File Manager clients.
6) tracking system calls to a pid and process name, so you can filter
on what a particular process does/did.
7) refactoring compiler invocations, etc., to take common sets of
arguments and store them in a shell variable.
8) Some more semantic interpretation of files and paths based on
extension, magic, etc.
The overall goal is to attack the Darwin self-hosting issue from the
tools end, instead of emulating Xcode in a top-down approach.
Accomplishing these sets of tasks would get you either some
straightforward shell scripts, or possibly makefiles. There should
also be intelligent diffing of the end results so you can see what
changed between software updates (like a new file was added, and this
is immediately obvious).
Some of these steps can be done independently and non-sequentially.
If you're interested in some of these issues, and want to coordinate,
let me know.
Shantonu
More information about the darwinbuild-dev
mailing list