site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Mar 10, 2006, at 5:20 AM, Andrew Gallatin wrote: For early development, I find it easiest to build in an NFS mounted volume and simply load my kext from there. That way, if something explodes, I can skip steps 2-3. Here is a makefile snippet: unload: mydriver.kext sudo kextunload -m com.mycompany.iokit.mydriver Now all I do to load the driver is "make load". When^H^H^H^Hif it crashes, I have the symbols ready to go. The only drawback is that the NFS fs must be exported with root=0 to avoid running into the bug that requires kexts be owned by root:wheel. -- Terry Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Terry Lambert writes: For symbolication for kext debugging, there's a knowledge base article on kext debugging on developer.apple.com that covers things pretty thoroughly, but here's the gist of it: (1) Get a debugger attached to the machine that has the kext that you want to debug loaded (2) Use the "showallkmods" command to get the load address for the kext (3) Execute the command "kextload -s /tmp -n <my_kext_name.kext>"; it will ask you for the load address (replace "<my_kext_name.kext>" with whatever your kext is) (4) Add the symbol file into the debugger using the "add_symbolfile <symbol_file_name.sym>" (replace "<symbol_file_name.sym>" with the name of the symbol file that was generated by the "kextload" command in step 3) (5) Happy Debugging! load: mydriver.kext sudo chown -R root:wheel mydriver.kext (sudo kextload -s . -r . mydriver.kext; sudo chown -R $ (USER):wheel mydriver.kext) You might want to do the chown before you try loading it, or the first time will always fail... That's a feature, not a bug. The intent is to make it impossible for third parties to demand-load a KEXT that does malicious things behind your back, without you first granting explicit authorization during the install by typing your admin password. If it were not this way, it'd be trivial to compromise your machine from a shell account. Obviously, if this bothers you enough, you can download the kextd sources from: <http://darwinsource.opendarwin.org/10.0.4/system_cmds-175.2/kextd.tproj/

And compile up your own copy that removes this restriction. I recommend that you do not do this; if you do it anyway, I recommend you do not give people shell access to the modified machine. This email sent to site_archiver@lists.apple.com