Re: Early lowlevel startup of user processes (crt1.o ... )??
Re: Early lowlevel startup of user processes (crt1.o ... )??
- Subject: Re: Early lowlevel startup of user processes (crt1.o ... )??
- From: Shantonu Sen <email@hidden>
- Date: Sun, 26 Jun 2005 23:11:20 -0700
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
40opendarwin.org
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden