On 2008-04-08, Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
> wrote:
> On Apr 9, 5:21 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
> wrote:
> ...
>
>> There is no reason to use elf if it is not native. There is no
>> reason that things would get more complicated.
>
> Hmm.. maybe but I get the feeling most IA-32 *nix's support elf in
> some form. As I understand it even FreeBSD binaries are elf. I don't
> know that it wouldn't be that difficult for Apple to have support for
> both heh.. But anyways, pondering about that won't change things.
>
> Albert:
>> I wote:
>> >If anyone's so inclined to advise me on how to 'section' out the
>> >source code a little better I'd be very grateful.
>>
>> Ah. I saw you made the dictionary a .text section.
>> That will not result in a fully usable Forth.
>
> Actually I put the .text immediately on the line before the .data
> directive. The apple NASM 0.98 would not assemble it as a mach-o
> without the .text section.
>
> To put this in context for everyone, I am using NASM (apple Xcode 3.0)
> 0.98 to assemble a patched Albert's lina into mach-o binary (which was
> originally meant to build elfs on linux)
>
>> Sections have independant properties:
>> 1. they can be protected against writing once loaded
>> (we don't want that in classic Forth, variables couldn't be
>> changed)
>
> My limited understanding (and trial and error lol) taught me that - I
> finally realized that so I put all the code in a .data segment as
> stated above (from the entry point start)
>
> As you say I initially put all the code bits in a .text segment but
> the kernel grumbled about it on excecution - and rightly so.
>
> The version you downloaded can write to the dictionary. It also does
> create does> and allot as far as my initial testing goes. Or should I
> say CREATE DOES> etc (I hadn't realised intiially it was case
> sensitive, heh).
>
> I found out however at the moment whenever I try and call an undefined
> word (say) from the interpreter it goes as far as printing xx? and
> bombs.. I'll have to trace this.
>
> I have to admit I'm still not completely familiar with the tools I
> have on my mac. Apparently the Xcode gdb version is really good, so
> that's what I'm working on figuring out now.
>
>> 2. they can be in the disk image
>> (we want that for the occupied dictionary space,
>> but not for the 256 Mbyte of free dictionary space)
>> 3. They can be protected against execution.
>> (we don't want that, primitive words couldn't be executed)
>>
>> .text is a protected against writing, but not against execution,
>> unusable for forth.
>> .data has the protections reversed, equally unusable.
>> The trick is to get rid of those sections in a c-world where
>> both types are deemed indispensible and find out how to spell
>> out the correct properties towards the assembler.
>> We want sections:
>> kernel: readable writable executable, in the image ("bits")
>
> As I understand it as of now mach-o .data segments allow read/write/
> exec else the code wouldn't have run. I had to put in the .text
> segment before that to get it to assemble. Maybe that problem is
> solved
>
>> dictionary: readable writable executable, not in the image.
>
> I don't quite get what you meant 'not in the image' - does this imply
> uninitialized datat?
>
> Trying to get the dictionary space section initialised however is
> tricky. I looked up some ELF documentation and saw that .bss was for
> unitialized data, took a chance, put it in and it seemed to assemble
> and link. I'm still not sure if that's the proper way to do it.
>
> If I left it without the .bss directive I got an obj that was close to
> 67 megs big and an executable (which still ran!!) about the same
> length as I am guessing it allotted and zeroed it out
>
> As I understand it, when you assemble/link a Lina elf, essentially
> the executable contains the engine and the prebuilt words in a named
> 'forth' section/segment and the dictionay builds from the 'dictionary'
> section/segment which is pretty much uninitialised and hence does not
> get allotted into the exe file, but onto the memory map of the process
> on loading and execution of the elf.
>
> I think I've managed to get this going, whether this is the correct
> form for mach-o or not I am still not sure. The assembler got very
> annoyed with me when I tried to call the section with the code 'forth'
>
>> I wrote:
>> >Also I've been sleeping over what you said about the LINOS, Albert.
>>
>> >I think it would probably be best in the end to build a completely
>> >independent macho-o OS X forth fork with a XNUOS word for example as,
>> >as you say, there will be times when one will want to call XNU direct.
>>
>> I see that it would be better to rename the word to POSOS. (Posix
>> OS call) or XOS (uniX family Operating System Call)
>> The usage would not be much different between the Linux,BSD
>> and OSX. The implementation would be only slightly different.
>> In that way most of the library stays intact.
>
> Hmm...I'll see how different the calls are when I get a chance and
> think of a way to work round this.
>
> What will really throw a spanner in the works however is if Apple
> decides down the track that most people will call the kernel via a c
> libary (ie 'their' c library or whatever proprietary library they may
> build) and change the more primitive things around. Or maybe this has
> already happened. I'll have to look at the XNU source.
>
>> By the way, I don't fork. I have a sophisticated generic system.
>> (Everybody is entitled by the GPL to fork if he wishes too, though.)
>
> Re: fork - Ok maybe wrong choice of words :) If I ever get an OS X
> version running I intend it to be as close to ciforth as possible.
> Maybe if it's bug free enough it may return to you if you want it
> heh...
>
> I've still your source to dissect and it seems really very elegant and
> clever, just one tiny engine and everything else is in the dictionary.
>
>> The first thing to try is just leaving it to a native assembler and
>> a native linker. They know best how native executables look like.
>> Forget about elf. The wina version is not elf either.
>
> Sure. Been doing that with the (apple) NASM which is set up to build
> mach-o. And the apple ld.
>
> Maybe I will have to look at gas. But, you know, truth be told, mea
> culpa, part of my growing up was done on m$-dos/windoze. So you can
> see where my prejudice lies. As far as I can tell the gas supplied
> with Xcode is < 2.0.
>
> I don't like the AT&T syntax an order of operands and it would seem
> that the apple version does not allow the intel order of operands
> directive.
>
>> Nice to see someone building on.
>
> Nice to see some nice source to play with :)
>
> I still don't understand a lot about forth, *nix etc. This is an
> excellent learning opportunity, thanks to you.
>
> -----------
> TO DO LIST:
> -----------
>
> 1. Build mach-o binary correctly. This means understanding the load
> process, memory map expected of a program of this sort, and how you
> expect your source code to assemble and live in memory as well.
>
> - Regarding the ELF Lina source: I think I can understand how the
> initial engine and prebuilt words get set up in memory but I still
> don't understand how the ELF loader does your dictionary. The
> priviledges bit I undestand but where does it locate it in memory?
> Where should it locate it in a mach-o.. questions questions heh...
>
> 2. Find out why the console interpreter bombs with undefined words
> (bad syscall) - probably an incompatible syscall I guess. I'll have to
> debug.
>
> 3. Write an alternative POSOS call word and/or make LINOS etc
> compatible with the XNU. See (2)
>
> 4. SAVE-SYSTEM ... heh.
>
> I think I will cheat and write some c to see what it assembles to -
> wish I could get gcc to assemble to nasm so I can't read it without a
> headache though.
>
> Robert Spykerman
http://0xfe.blogspot.com/2006/03/how-os-x-executes-applications.html
may shed some light, but you won't be filled with joy ;(
l8r....
---
Duke Normandin
|
