site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) It's more an attempt to figure out what's required-- just educational. Ok, I'll try adding that. I was assuming (stupidly probably) that since I wasn't using threads that that wasn't required. Is it really true that what would normally be 'libc' requires pthreads? Thanks for the help! Shantonu On Jun 26, 2005, at 4:13 PM, Rob Ballantyne wrote: Hi, I'm trying to understand the early startup process. In particular I'm trying to build a standalone assembly language program (no crt?.o) that will link against libSystem.dylib. I've managed to link correctly against it for simple routines (atoi for example) but I've run into a problem attempting to use printf. The system cores on me. Witness: (gdb) run Starting program: /Users/ballanty/devel/AsmTest/test3 Testing...1,2, Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x90003464 in malloc () (gdb) where #0 0x90003464 in malloc () #1 0x90110d08 in localeconv_l () #2 0x9000fc30 in __vfprintf () #3 0x900fa088 in vfprintf_l () #4 0x90022318 in printf () #5 0x00001f88 in start () at test3.s:28 #6 0x00000000 in ?? () Cannot access memory at address 0x0 Cannot access memory at address 0xa Cannot access memory at address 0x0 Cannot access memory at address 0x0 #7 0x00000000 in ?? () Cannot access memory at address 0x0 Cannot access memory at address 0x0 Cannot access memory at address 0xa Previous frame inner to this frame (corrupt stack?) (gdb) It looks like it is linked correctly but I can't figure out why malloc is core-ing (looks like it's dereferncing a null pointer to me). I suspect there is some startup routing (initialization?) that must be called before some stuff from the C library can be called. Can anyone confirm that? In crt.c it appears the only significant thing that gets called is: __dyld_make_delayed_module_initializer_calls. The comment in the code seems to indicate it's C++ specific though!!! Can anyone confirm/deny my guess? I've examined: start.s, crt.c, and dyld.s. This appears it might be the problem. Many Thanks for any help! Rob _______________________________________________ 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/ssen% 40opendarwin.org This email sent to ssen@opendarwin.org _______________________________________________ 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... Shantonu Sen wrote: Why are you doing this? Why not start with a working crt1.o and remove what you don't want? Lots of things get called from crt.c, among them (*_cthread_init_routine)() in libSystem.B.dylib, which is responsible for initializing pthread state for the default thread. Without calling this routine, you're not going to get very far. Rob !DSPAM:42bf9892144684465477762! This email sent to site_archiver@lists.apple.com