[darwinbuild] some darwintrace ideas

[Kevin Van Vechten]

Good stuff.  I'm interested in taking all of these changes into  
darwintrace.  There's one major deficiency in darwintrace today that  
I'd like to add to the list:

9) the #! interpreter of shell scripts that are exec'd is not  
reported.  This should be reported as another execve(2) call.

I can implement a couple of these items.  I'll sync up once the  
darwinbuild-0.6 release is done.

- Kevin

On Jul 7, 2005, at 5:57 PM, Shantonu Sen wrote:


> 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
>