site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com --- Load commands segment segment segment section 1 section 2 section 3 --- Data otool (1) and nm (1) are also quite helpful. I'm sure it's doable, though it may take some experimenting. I believe that uuid_generate() simply ensures that the UUID is sufficiently random, so you can likely put whatever you want in the uuid_command with the understanding that if you are not actually unique (as much as one can be in a finite namespace), dire consequences may result. 1) Load kext A 2) Change kext A on disk 3) Load kext B Thanks, Cem Karan -Andrew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... As a question is/are the people responsible for keeping "Mac OS X ABI Mach-O File Format Reference" and "Mach-O Programming Topics" on the list? It might help if/when I/we file bugs to be able to point out this whole thread. Since this is an unofficial, unsupported list, there isn't really any way of knowing unless they speak up. It's probably best to include the relevant points in any Radars you file anyway. OK, that was what I thought was going on. The problem is that when I first saw the figure, I thought the following was happening: Hmmm... I guess the first bug I need to file is the need for some fairly complete examples of layouts of mach-o files (sans actual data/ code). I'll do that tonight Well, the only thing I'm thinking about is another long running mental exercise I've had; I'm working out a new (hopefully better) programming language. If I go to the effort of reading/writing the mach-O file format, then I may as well take advantage of it and see if I can't write a compiler to put something into it! :D And, like Objective-C, I'm going to need my own runtime, so it would be nice to be able to do this. Is there any way to determine if there is a collision besides 'dire consequences'? I can think of a few ideas on how to protect against problems, but they require the loader to be notified any time a new mach-O file is loaded onto the system so it can check, and, if necessary, modify, UUIDs for use on a particular system. I'm just not familiar enough with how UUIDs are used to be of much help on this. My guess is it doesn't matter too much, as long as you aren't trying to load the same binary with different UUIDs. For example, in kext land, presume you have 2 kexts, A and B, where B depends on A. In the following scenario: the load will fail because we'll detect the UUID change and flag an error. I would expect that userspace has some similar mechanism, though probably much more complex :) I agree, I'd like to release it someday (assuming I get anywhere with it!) This email sent to site_archiver@lists.apple.com