Sections in assembler forth's on un*x
Albert van der Horst
of lina on linux and xina on OSX set me thinking and experimenting.
I declared with emphasis that the normal sections are unusable for Forth,
not being executable or not being writable.
However, because the .text .data and .bss sections are special, they
are known to the linker and may be treated as special by the linker.
They do! It turns out that there is a linker flag, that makes the code
section writable. It is the -N or --omagic flag. At least it is
supported by the GNU loader.
With this option we can put the kernel in the .text section.
The .bss can be used to define the layout of the free dictionary
space, such as where the tib is, block buffers and stack space.
It doesn't follow, that code assembled here can be executed, but
on linux it apparently does, at least as far as my experiments go.
This doesn't interfere with the SAVE-SYSTEM as used in lina at all.
Also ``lina -c hello.frt'' generates an executable.
I have implemented this in my latest beta.
On my site the beta 5.35 version of lina is available. This contains
sources and documentation. The upcoming version 5 is different from
4.0.6 in significant respects, notable using WANT instead of REQUIRE.
Furthermore there is still a known defect: the -g options (to change
the memory size available to Forth) gives a bus error.
In this latest beta, the word LINOS is renamed to XOS. (I'm glad
version 5 has not been released, or otherwise this would have to
wait.)
The above is relevant to attempts to port lina to other X-like
systems like OSX. Using standard sections and options to the linker
(as opposed to patching binaries) greatly improves chances of
successful porting.
So have a look at lina.html at my site below.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Robert Spykerman
wrote:
> Recent discussions about specification of sections and linking
> of lina on linux and xina on OSX set me thinking and experimenting.
>
> I declared with emphasis that the normal sections are unusable for Forth,
> not being executable or not being writable.
>
> However, because the .text .data and .bss sections are special, they
> are known to the linker and may be treated as special by the linker.
> They do! It turns out that there is a linker flag, that makes the code
> section writable. It is the -N or --omagic flag. At least it is
> supported by the GNU loader.
As you probably realize, Albert, OS X unfortunately does not use the
standard ld linker.
Recapping the discussions with Josh on patching privileges on the mach
header so that the __TEXT and __DATA segments are rwx (it, of course,
works) - I found that a bit inconvenient after a few reassembles.
It turns out the linker has a 'rarely used' option -segprot
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html
so:
$ ld forth.o -segprot __TEXT rwx rwx -segprot __DATA rwx rwx -o forth
Now I believe you got both your text and .bss in one segment, under
linux, didn't you Albert?
I'm still figuring out if this is possible under OS X but I don't
think so.
Robert Spykerman
Albert van der Horst
Robert Spykerman <robert.s...@gmail.com> wrote:
>On Apr 13, 2:21 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>
>> Recent discussions about specification of sections and linking
>> of lina on linux and xina on OSX set me thinking and experimenting.
>>
>> I declared with emphasis that the normal sections are unusable for Forth,
>> not being executable or not being writable.
>>
>> However, because the .text .data and .bss sections are special, they
>> are known to the linker and may be treated as special by the linker.
>> They do! It turns out that there is a linker flag, that makes the code
>> section writable. It is the -N or --omagic flag. At least it is
>> supported by the GNU loader.
>
>As you probably realize, Albert, OS X unfortunately does not use the
>standard ld linker.
I wouldn't phrase it like that. The standard linker on OS X is not
the familiar GNU loader.
When in Rome, do as the Romans do.
Is there a standard assembler for OS X?
What happens if you feed it either the .s (gas) or the .asm (nasm)
file?
I'm willing to put some work into adapting the source
to this standard assembler.
I would not abandon the standard tools, unless and before severe
difficulties are encountered.
>
>Recapping the discussions with Josh on patching privileges on the mach
>header so that the __TEXT and __DATA segments are rwx (it, of course,
>works) - I found that a bit inconvenient after a few reassembles.
>
>It turns out the linker has a 'rarely used' option -segprot
>
>http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html
>
>so:
>
>$ ld forth.o -segprot __TEXT rwx rwx -segprot __DATA rwx rwx -o forth
I figure the above ld is the OS X loader.
-segprot looks like the OS X equivalent of the -N option, but more flexible.
>
>Now I believe you got both your text and .bss in one segment, under
>linux, didn't you Albert?
I have the kernel in the text, and the buffers, stack free space etc.
in bss.
This version has the advantage that at least the section names
are familiar to BSD assemblers and linkers.
So it looks like
$ ld forth.o -segprot __TEXT rwx rwx -segprot __BSS rwx rwx -o forth
would do the job.
>I'm still figuring out if this is possible under OS X but I don't
>think so.
If the above works in setting write and execution modes, you're
all set. And pretty straightforward after all.
I promise to help in hacking out the SAVE-SYSTEM stuff.
>
>Robert Spykerman
Robert Spykerman
wrote:
...snip...
> Is there a standard assembler for OS X?
Well, there's an Apple as with the gcc that came with Xcode 3.0. I'm
pretty sure this gas is under version 2.0 from memory. ( and I believe
the gcc is 4.0 but I'm not able to check at the moment). It did not
correctly identify the intel operand sequence directive.
Apple also to their credit provided an apple nasm (0.98). The main
difference of this apple version to the late 'common' versions of 0.98
is that it knows how to assemble mach-o .o's.
I built nasm 2.02 on OS X - it also appears to know mach-o's. But
given that Apple has not provided it, until I fully understand it I am
currently using the Apple one - I don't notice any significant
differences, to be quite honest.
> What happens if you feed it either the .s (gas) or the .asm (nasm)
> file?
The gas file bombs spectacularly, if I recall it was mainly because of
the lack of the intel syntax directive...
Wait, if you're talking about your beta 5 version, I've not tried
that yet - I admit.
I have a working binary based off your version 4 at the moment - most
syscalls corrected, including that nefarious difference of lseek
between bsd and unix (that one had me for a while till I realized the
offset was 64 bits on bsd)...code/kernel in text (__TEXT) _segment_
and the userspace etc in the dat (__DATA.bss) segment. (.bss is part
of the data segment at least on mach-os I believe).
http://xina.cvs.sourceforge.net/xina/xina-generic/
( excuse the chaos - still completely haven't understood how to use
cvs effectively yet )
The only differences to the source lina original are bits of
conditional assembly to LINOS, LINOS5, and certain words in the system
ie REPOSITION-FILE have had to be corrected for the lseek difference.
Notably, I've had to add an
XOS ( nx nx-1 ... n2 n1 x syscall-no -- ior ) where x is the number
or parameters to the sycall so that it can clean up the stack after -
I think the comments in the source may need updating.
From memory I think I added a few other things to the base dictionay I
kind of like like -ROT.
I'm not sure if I corrected execve yet for forking, I think I may have
corrected the vector no. but haven't tried it out yet.
The source could be cleaned up a little bit more and that will happen
as my understanding of how lina is put together improves. A lot of it
is built on uncommented forth in the form of assembly constants. I may
add comments as I go along as I think that may make things better for
whomever comes after.
Otherwise,
Basically you have a source file that will assemble conditionally on
linux (per your original) or on a mac OSX (and possibly BSD) and the
OSX linked one appears to run now fairly unbuggily - so that's an
alternative - things to fix now are the SAVE-SYSTEM and give the other
words that make syscalls a good testing. The big lseek bug is fixed.
> I'm willing to put some work into adapting the source
> to this standard assembler.
Well, then there are two choices. Apple nasm and gas. Our mutual build
tools may intersect closest on nasm 0.98, and I'll admit a personal
bias. gas you're running is version 2+ and the apple one hasn't hit
2.0 yet... but I'll do gas too if you prefer.
> I have the kernel in the text, and the buffers, stack free space etc.
> in bss.
Hmm.. interesting. May not get a chance to try your latest for another
24-48 h but will give it ago. I will see how my linker or dyld loader
likes it.
> Albert van der Horst, UTRECHT,THE NETHERLANDS
Robert Spykerman
Albert van der Horst
Robert Spykerman <robert.s...@gmail.com> wrote:
>
>The gas file bombs spectacularly, if I recall it was mainly because of
>the lack of the intel syntax directive...
>
>Wait, if you're talking about your beta 5 version, I've not tried
>that yet - I admit.
Don't waste your time trying. The .intel syntax is progress.
Old format is not applicable to 5.
<SNIP>
>
>
>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>
>Robert Spykerman
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Robert Spykerman
wrote:
..
> Robert Spykerman <robert.spyker...@gmail.com> wrote:
> >The gas file bombs spectacularly, if I recall it was mainly because of
> >the lack of the intel syntax directive...
> >Wait, if you're talking about your beta 5 version, I've not tried
> >that yet - I admit.
>
> Don't waste your time trying. The .intel syntax is progress.
> Old format is not applicable to 5.
LOL.
Anyways, right now I'm trying to port the SYSTEM word.
The fork syscall appears to work (I get another forth instance on top
of the old one) but the shell does not get called to do say, something
quick like "ls" SYSTEM. I changed the vector to the apple one, maybe
there's a difference. I also had to patch waitpid - it's wait4 on the
apple.
I just can't think of what the problem is. Been going thru' your forth
source in the file, and it looks like it should work with my ported
syscall hooks (apart from waitpid which had to be fixed to a 4
parameter syscall). All the path, args and environmental variables are
all accessable.
Gonna isolate the calls later in a separate test and see.
I thnk the problem is in execve though. Has anyone had any other
experience of a smiliar nature?
Basically I believe this is hopefully the last of the syscalls to fix,
once this is done, it's time to move on to SAVE-SYSTEM.
Robert Spykerman
wrote:
> Anyways, right now I'm trying to port the SYSTEM word.
>
> The fork syscall appears to work (I get another forth instance on top
> of the old one) but the shell does not get called to do say, something
> quick like "ls" SYSTEM. I changed the vector to the apple one, maybe
> there's a difference. I also had to patch waitpid - it's wait4 on the
> apple.
Just a brief update re: my attempt at porting Albert's ciforth to OSX
I've found out what appears to be the problem afflicting my current
attempt at porting the SYSTEM word.
It would seem that the fork syscall appears to return the PID to both
parent and child process which results in the child not knowing it's a
child (because it would expect a PID of zero) and hence execution
pretty much waits there.
I am not sure what's affecting fork and why it's behaving this way, it
must be a porting glitch on my part, but so far the code really looks
quite sane.
How hard is it to call a pid_t fork (void) ...
where pid_t = unsigned 32 bit, ie return a 32 bit value (which I
assume will sit in EAX and appears to otherwise I would not get a PID
back at all, so given I'm getting PID's back I must be doing that bit
right :).
The linux code works as it self describes really, I've double checked
the return values and they check out. Child gets 0. Parent gets PID of
child.
Can't see what I'm doing wrong with my OSX version both get the PID of
the child.... hmmm..
I can't believe even I can stuff that up :) But who knows hehehehe.
/scratches head.
Anyways it would seem all things being equal I may get some time to
work on this this weekend... If anyone's ever come across a problem
like this before, pray do share your wisdom. I'll see if any of the
BSD or mac guys I know have come across anything like this as well.
Robert Spykerman