Re: Forth for Mac OS X Leopard (Intel) - what are the options?

Regarding building ciforth/Lina for OS X  ...

Firstly, thanks for making that available - it's a fantastic resource
I've really quite neglected to look at while exploring forth.

On Apr 5, 6:44 pm, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
> In article <jytq5r....@[EMAIL PROTECTED]
>,
> Albert van der Horst  <alb...@[EMAIL PROTECTED]
> wrote:
> <SNIP>
>
> >You *got* to find out how to do a system call, and how to pass
> >parameters. In Linux this is : parameters in AX BX CX.
> >System call is
> >      INT 0x80
> >      DD  <syscal nr>
>
> Sorry of course this is:
>
> In Linux this is : parameters in BX CX DX
> <syscal nr> in AX
> System call is
>       INT 0x80
> So no interspersing of code and data.
>
> I found information on the internet, suggesting that
> this works the same way on a Mac Intel, except for
> register DX.
>
> >This is tricky and documentation may be hard to find, but it is
> >not really difficult for a hacker.

Been looking and I _think_ I may now know how to call the OS X kernel
(intel). One may be able to call the OS X kernel with these (hopefully
correct) assumptions :

1. The kernel function no.s/jump tables are all the same or fairly
similar across the board. As you say, they appear to be similar
between BSD and Linux.

2. They can all be accessed by an int 0x80.

3. The pattern appears to be in linux the parameters as you say are
passed in registers. However in BSD and the OS X kernel XNU, so far it
seems to me, EAX carries the function call no. and the rest of the
stuff is _pushed_on_to_the_stack_ (ie ESP).

I do not believe these hold universally, they seem to for simple io
I've tested (ie output to console, files), but these are VERY
preliminary.

Now porting Lina:

First, the (hopefully) easy bit. Unfortunately I think the order of
parameters is reverse from the way your hard coded words in Lina call
the _syscall mechanism you use to call the linux kernel (ie LINOS and
LINOS5).

The 2 ways that immediately come to my mind to fix this are

1.  the more predictable one is to fix LINOS and LINOS5 to reorder the
stack and then do an int 0x80. I think I favour this lazy way out as
the other way would be to rewrite all the words that call LINOS and
LINOS5. The advantage of course is user code calling said functions
won't be broken. The code to do this is ugly however - see right
below.


2. Just rewrite the prebuilt forth words to reorder the parameters. A
little bit more work but doable but user code out there could be
broken. However I expect few people would be calling LINOS directly...
or maybe I am wrong.

All potentially a pleasant evening's work EXCEPT

*** LINKING ***

As you say, one needs to know how to link.

This is very painful given my lack of knowledge of certain
fundamentals of OS X and linux binaries - how they link etc..

I do not fully understand yet:
1. The ELF binary format
2. And of course, mach-o
3. Lastly I guess I've just had your source for 8 hours :) I'm
printing a copy...

Have you any suggestions?

I have a (somewhat) running executable. Please feel free to comment/
patch/debug/cast stones/burn etc... :)

MAC OS X INTEL port of lina available for download (source and
executable)

http://savefile.com/projects/808626874

Be wary, not all linux calls map 1 <-> 1 OS X.

If any one EVER gets a complete reference of all the direct OS X XNU
kernel calls, please please please please please send it my way :)

As for me, I've been awake the whole weekend at work and spent the
whole morning resetting my clock doing this, so it's time for bed
before I start looking at it any further.

Robert Spykerman