In article
o1g2000pra.googlegroups.com>,
gmail.com> wrote:>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
>wrote:>> In article
,
>> Albert van der Horst wrote:
>>
>>>>>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
>>
>> Sorry of course this is:
>>
>> In Linux this is : parameters in BX CX DX
>> 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.
This is the way to go. That is where LINOS was factored out for.
>
>
>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.
LINOS is used in the library, so you would have to patch the
library too. No it is not a good idea.
Calling LINOS is useful:
I recently was experimenting with time outs on reading
from serial ports.
10 _ _ 27 LINOS
(with _ is don't care)
sends an alarm signal in 10 seconds.
Then a small CODE word and another LINOS call (to set traps)
turns the signal into a THROW, such that an infinite loop
is terminated and can be CATCH-ed in 10 seconds.
This is an alternative to a situation where you can only
use facilities that are expressly imported into a Forth via
c-libraries. The advantage is that you are not held back
to experiment with any system call.
>
>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?
If the elf format is used, that is already nice, because it is
well documented.
Use a standard assembler if available.
Use the standard linker.
See what happens.
E.g. with nasm on linux
nasm -felf lina.asm -o lina.o
ld lina.o -o lina
It doesn't get much simpler than that.
It worked when I knew nothing more about the elf-format
than that it existed.
Now SAVE-SYSTEM was a little more work.
>
>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)
If the executable runs, you can ask
make testlina
in the generic environment, and find out where it crashes ;-).
>
>
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 :)
On some unix systems
man 2 syscall
provides valuable clues.
>
>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.
I'm kind of busy at the moment, but I'll try to have a look at
your source tonight.
>
>Robert Spykerman
Groetjes Albert
