On Apr 9, 10:18 am, Duke Normandin <dukeofp...@[EMAIL PROTECTED]
> wrote:
> On 2008-04-08, Robert Spykerman <robert.spyker...@[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
Nope, you're right.
Anyways, on the current executable downloadable, I've traced the
current bad system call to vector 0x0C, if I am correct. Current
executable bombs when the console interpreter finds an undefined word
or a redefined word.
I've got to dig up XNU internals and linux and see what the big
difference is, when I have time but I've got to actually get back to
real life lol
Robert
|
