[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