On Apr 30, 4:58 pm, Ben Artin <mac...@[EMAIL PROTECTED]
> wrote:
> Are you sure you know the calling conventions? They are do***ented at
>
<http://developer.apple.com/do***entation/DeveloperTools/Conceptual/Lo...
> rticles/IA32.html#//apple_ref/doc/uid/TP40002492> for IA-32 and
>
<http://developer.apple.com/do***entation/DeveloperTools/Conceptual/Lo...
> rticles/x86_64.html#//apple_ref/doc/uid/TP40005035> for x86-64
>
> I am unclear on why you are referring to BSD do***entation, when Apple's
> do***entation is available (and possibly different -- Mac OS X does not
use the
> BSD kernel).
True. Fortunately the calling conventions are adhered too. I just
checked the apple IA-32 ABI, looks pretty much what I expected for
IA-32 'C'.
Fortunately my assumption in this case (which I agree may have been a
little loose) was correct.
In truth, I'm still kind of new to OS X, still don't really know where
to find everything, so thank you for that.
> The source for the fork syscall is in
>
<http://www.opensource.apple.com/darwinsource/10.5.2/xnu-1228.3.13/bsd...
> fork.c>. One notable aspect of it is:
>
> retval[0] = child->p_pid;
> retval[1] = 0; /* flag parent */
>
> which does, indeed indicate that the return value of the fork syscall on
Mach
> consists of two parts; if you look in the calling convention do***ents I
> mentioned above, I believe that you will find that those two parts are
returned
> in EAX and EDX, respectively.
Thanks, that really helped. I'm still groping around finding out where
everything lies in the source, and to those of you who have pointed me
to that file, thanks verymuch.
At least I know why the code is behaving the way it is, and for my
purposes at least, I believe it's behaving correctly.
> That prototype is for the C library fork() call, not for the fork
syscall. I am
> wondering whether you'd be better off calling the C library, which has a
sane
> calling convention.
Agreed, that is probably a good idea - I may well decide to rewrite
everything to this extent. I have to say though, it irritates me
somewhat that I may have to add another intermediate layer between the
code and the kernel, but I can see how this would avoid future
problems should syscalls change.
Robert Spykerman
|
