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

In article <94cdc3ff-fc7f-495a-acdb-83c1319f0a09@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Robert Spykerman <robert.spykerman@xxxxxxxxx> wrote:
On Apr 9, 5:21 am, Albert van der Horst <alb...@xxxxxxxxxxxxxxxxxx>
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.

Using elf solves some problems, using native formats solves
probably more problems.
<SNIP>

As I have some notes, that are more or less independantly readable,
I snipped the rest of the article. If I would phrase the remainder
as responses it would become hard to read, I think.

1.
Indeed it is true that some assemblers mandate certain
sections.
In general there is a trick to get rid of unwanted sections
afterwards: the strip command. I had to do that for nasm,
especially in behalf of SAVE-SYSTEM.

2.
If the .data section works for the kernel part of xina, that is
fine. I'm slightly surprised that it is executable.

A test to do is the following:
0 PREV !
This will change a variable in the kernel, and would bomb out
if the kernel was implemented in a classic .text section.

3.
What you experience with large executables is the issue I
mentioned with sections not to be written to the disk image.

A "nowrite" section (or whatever it is called in Your Favorite
Assembler) cannot contain code or data. Instead it defines
a layout of memory, so only pointers into it are of interest.
These pointers are known to the program at large, and are filled
in by the relocating linker where they are referenced in other
sections.

An example may clarify this. The stacks are in unitialised memory.
The initial value of a stack pointer is a fixed place there.
This must be a known address to the kernel. You don't want
a 64 Mbyte stack in the disk image, and there is no initialised
data there, so this is a candidate for a nowrite section.

4.
You want the initialised and the unitialised part of Forth
to be in that order, and without a gap.
This is the default way a sensible linker handles this
if the unitialised section follows the kernel in the source,
but there is no guarantee, especially not over different OS's.
The official way is to use linker scripts.
Also default linking will select a start address for you.
For some reason a normal start address in linux32 is around
HEX 0804,0000 and on linux64 it is HEX 0000,0060,0000,000.
You don't want to think about where to find documentation
to select a reasonable address here. It certainly takes more
time to then porting to linux64 has take me now ;-).

I have some experience with linker scripts in GNU (for embedded
work) and it is an issue to avoid if at all possible.

5.
If the changes of OSX compared to linux are as small as it looks now,
I will certainly add OSX as an option to the generic system, with its
own configuration file osx.cfg.
Then you can generate tailor made pdf, html and info documentation
for osx (for the kernel at least).

6.
The generic system can spit out Intel code palatable for gas,
and *even the old gas code with the operands reversed*
(before the ".Intel_syntax prefix" directive).
If that is the way to go, so be it. It is clear that I will get
to be more involved to start that up.

I'm indebted to the authors of nasm, as I used it for
years for the main versions, even building the Windows versions
on linux. But gas delivers the same advantage to me as gcc
for gforth, it allows me to port to other processors easily.
The port to AMD64 was a few evenings work thanks to that.
(I wished they would at least allow the standard ; for comment,
instead of #, though.)

7.
There is nothing wrong with looking into the output of the
c-compiler. The -S option is your friend. I do that a lot.
It doesn't really entitle you to the information you get,
but at least it is correct.
(It wears off. The most simple code on linux64, only
issuing a write system call and static linking, generates
600 kbyte of assembler.)

8.
Apple moving the numbers of syscalls around? Hmm. They
would certainly create a lot of trouble for themselves
and their customers, not the least that no old executable
would run. Not all hope is lost, even then.

The generic system contains c-code to steal those (and other)
constants from the c-compilation system. It is called stealconstant.c.
It is system-dependant, and must be run - of course - on the system
whose constants you want to steal.


Robert Spykerman

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

.

Relevant Pages

  • Re: [PATCH] CodingStyle: add typedefs chapter
    ... The reason we have them for things like pte_t etc. is that there ... then by all means go ahead and use a typedef. ... New types which are identical to standard C99 types, ... covers RTL which is used frequently with assembly language in the kernel. ...
    (Linux-Kernel)
  • Re: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
    ... to relocate the ELF cannot be executed at the wrong place. ... of the chunk of memory that the linux kernel needs. ... - Find a hole in the memory map that meets those requirements. ... else to do a bit-to-bit comparisson after the crash, and so no relocate. ...
    (Linux-Kernel)
  • [UNIX] Linux Kernel ELF Core Dump Privilege Elevation
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... A locally exploitable flaw has been found in the Linux ELF binary format ... privileges and also execute arbitrary code at kernel privilege level. ... memory access error) occurs during the execution of the binary. ...
    (Securiteam)
  • Re: [PATCH] stronger ELF sanity checks v2
    ... > There is no ELF version bumping anywhere on the horizon. ... For much the same reasons that I want to check everything else. ... In both cases I see no reason why the kernel should not throw out the ... "The ELF header's e_flags member holds bit flags associated with the file. ...
    (Linux-Kernel)
  • Re: SuSE: migrating tot linux software RAID?
    ... > third machine with a megaraid that crashed because of this kernel ... >> The reason that you had data loss at all... ... > I had backups and successfully restored the system after a full install. ...
    (alt.os.linux.suse)