is Mac OS X syscalls == BSD ??? (needed fiest 10-20 calls for wr/rd/...)

Томас Гриштар, товарисч, шо там у нас с MacOS???

funny... ))) so many replies)))

but I already finded... i think))) NeXTStep - is from BSD tree... so... ))

NextStep is a combination of parts from different Unix versions, including BSD, but it's not part of BSD.
I don't know what their system calls are.

Grysztar, will you have an opportunity to port fasm to Mac OS X ?

By the way, thanks a lot for fasm's powerfull macroprocessor which supports recursive macros, which is very practical to generate FreeForth symbols table in the reverse order of symbols declarations.

I have been planning it for a few years already. There was someone here on forums that promised me to share some x86 Mac machine so that I could do a development on it, unfortunately it didn't succeed (and I haven't heard from him in a while). I may still try to develop it without any access to real machine, though (just as I did with x86-64 initially) - the Mach-O output format is currently planned for the 1.70 milestone (earlier I thought it would be 1.68, but because of the aforementioned problems it got postponed).

I have a Mac running OS X ver 10.5.8 Intel. How can I help. I have all the developer tools installed.
I know C, C++, gas and a little fasm.

echd@rawbw.com

Tomasz, you don't know anyone from work or neighborhood who would loan you their Intel Mac for testing? How much is the cheapest Mac selling for in Poland? Perhaps a Mac Mini (assuming you have all the accessories already)?

P.S. I think ronware already (!) converted RevaForth to use NASM now instead of FASM due to no Mach-O support.

Not having a machine for test was just a lame excuse.
It would not the first time I would be implementing something I'd not be able to test myself.
I just changed the order of things I was working one (like "fas" format support) and that's why Mach-O support is late. But I'm going to add it soon.


On the other hand, before it's really - are there really no tools that would be able to convert ELF to Mach-O, etc?

Agner's ObjConv (or here for DOS version) might work, but I haven't tested it from ELF -> Mach-O (don't have a Mac).

Greetings all, thought I would share how I went so far w/ the aforementioned ObjConv tool and the fasm libc...

../objconv/objconv -fmac -nu fasm.o fasm_mac.o

Input file: fasm.o, output file: fasm_mac.o
Converting from ELF32 to Mach-O Little Endian32
Adding leading underscores to symbol names

0 Debug sections removed
0 Exception sections removed
14 Changes in leading underscores on symbol names

Then:
ld -o fasm_test fasm_mac.o /usr/lib/crt1.o -lc

file fasm_test
fasm_test: Mach-O executable i386

when run however, immediately segfaults with:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x8fe18c02 in __dyld_misaligned_stack_error ()

A quick dig around indicates that libc calls on os x require 16 byte stack alignment, as evidenced by:
; aligns esp to 16 bytes in preparation for calling a C library function
; arg is number of bytes to pad for function arguments, this should be a multiple of 16
; unless you are using push/pop to load args
%macro clib_prolog 1
mov ebx, esp ; remember current esp
and esp, 0xFFFFFFF0 ; align to next 16 byte boundary (could be zero offset!)
sub esp, 12 ; skip ahead 12 so we can store original esp
push ebx ; store esp (16 bytes aligned again)
add esp, %1 ; pad for arguments (make conditional?)
%endmacro

Will investigate a bit further and let y'all know if I get it to work
Cheers

Just as a quick test, I did up a quick and dirty hello world libc call, compiled the object file w/ fasm on one of my linux machines, converted it to mac w/ ObjConv, ran ld similar to my last post, ran it with no dramas:

../fasm osxtest.asm osxtest.o
flat assembler version 1.68 (16384 kilobytes memory)
3 passes, 493 bytes.

../objconv/objconv -fmac osxtest.o osxtest_mac.o

Input file: osxtest.o, output file: osxtest_mac.o
Converting from ELF32 to Mach-O Little Endian32

0 Debug sections removed
0 Exception sections removed

ld -o osxtest osxtest_mac.o /usr/lib/crt1.o -lc

./osxtest
Hello world!

uname -a
Darwin PodDesk.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

osxtest.asm:
format ELF

section '.text' executable
public _main
extrn _printf

_main:
push ebp
mov ebp, esp
push ebx

mov ebx, esp
and esp, 0xfffffff0
sub esp, 12
push ebx
add esp, 16

mov dword [esp], hellomsg
call _printf

sub esp, 16
pop ebx
mov esp, ebx

pop ebx
mov esp, ebp
pop ebp
mov eax, 0
ret

section '.data' writeable

hellomsg db 'Hello world!',0xA,0

Hi Redsock,

I'm interested in your progress. I've been able to reproduce your results using objconv and the subsequent misaligned stack. I'm curious to know what other work you've done in this area and I'd be happy to perform any tests you've considered but haven't yet tried.

Here's a list of many of the kernel level library routines used by fasm:

$ cat dis.gdb
disassemble main
quit
$ gdb ./fasm_test -x dis.gdb | grep dyld_stub_
0x00001959 <main+121>: call 0x16077 <dyld_stub_gettimeofday>
0x000019b4 <main+212>: call 0x16077 <dyld_stub_gettimeofday>
0x00001b8e <main+686>: call 0x16081 <dyld_stub_malloc>
0x00001bd1 <main+753>: call 0x1605e <dyld_stub_free>
0x00001bd9 <main+761>: call 0x1604a <dyld_stub_exit>
0x00001be7 <main+775>: call 0x16072 <dyld_stub_getenv>
0x00001c1e <main+830>: call 0x16054 <dyld_stub_fopen>
0x00001c63 <main+899>: call 0x16054 <dyld_stub_fopen>
0x00001c77 <main+919>: call 0x1604f <dyld_stub_fclose>
0x00001c8a <main+938>: call 0x16059 <dyld_stub_fread>
0x00001ca9 <main+969>: call 0x1606d <dyld_stub_fwrite>
0x00001cc3 <main+995>: call 0x16063 <dyld_stub_fseek>
0x00001ccf <main+1007>: call 0x16068 <dyld_stub_ftell>
0x00001cfb <main+1051>: call 0x1608b <dyld_stub_write>
0x00001efa <main+1562>: call 0x16086 <dyld_stub_time>
$

(Is this list complete?)

crt1.o provides many other services, e.g., start, exit.

There should be a process for providing versions of these routines which create 16 byte aligned stack frames. Yet, one should still be able to link against crt1.o.

Any tips?

Because fasm's libc version uses "ccall" macro to call the libc routines, it should be enough to rewrite this macro to make it align the stack properly.
This macro is defined in the beginning of source\libc\fasm.asm.
Also there may be some places, like "call exit", where the ordinary "call" would have to be replaced with "ccall".

Thanks Tomasz! I'll give that a try this evening! I'll build the fasm.o from a modified source in my Linux box.

Thanks! LaFarr will surely appreciate this!

Why do not try Emulator of x86/PPC ???

Hi Narada,

As an employee and shareholder of VMware, I'd be happy to see more people use Fusion to emulate a PC so they could simply run DOS or Windows or Linux, etc.

However, virtualization is such a heavy handed tool. I'd much prefer to help people use the power of a tool like fasm where it's appropriate.

Thanks Tomasz! That worked great.

Let me know if you'd like a binary that you can post for people to download and use. It's about 85KB.

Just as you suggested, I patched two files. Here are my differences:

$ diff -du fasm-orig/source/libc/fasm.asm fasm-mac/source/libc/
$ diff -du fasm-orig/source/libc/system.inc fasm-mac/source/libc/

If you have any better ideas for the ccall macro, I'm certainly open to alternative implementations. However, the results are quite compelling, after initially having had used this macro on a Linux system to create the ELF version of fasm.o, I then brought it over to the Mac to self assemble, and then re-self-assemble with the new results and see that there was no difference:

$ ./mac_fasm source/libc/fasm.asm mac_fasm2.o
flat assembler version 1.68 (16384 kilobytes memory)
4 passes, 100139 bytes.
$ objconv -fmac -nu mac_fasm2.o mac_fasm2.mach-o
<objconv output>
$ ld -o mac_fasm2 mac_fasm2.mach-o /usr/lib/crt1.o -lc
$ ./mac_fasm2
flat assembler version 1.68
usage: fasm <source> [output]
optional settings:
-m <limit> set the limit in kilobytes for the available memory
-p <limit> set the maximum allowed number of passes
-s <file> dump symbolic information for debugging
$ ./mac_fasm2 source/libc/fasm.asm mac_fasm3.o
flat assembler version 1.68 (16384 kilobytes memory)
4 passes, 100139 bytes.
$ objconv -fmac -nu mac_fasm3.o mac_fasm3.mach-o
<objconv output>
$ ld -o mac_fasm3 mac_fasm3.mach-o /usr/lib/crt1.o -lc
$ ./mac_fasm3
flat assembler version 1.68
usage: fasm <source> [output]
optional settings:
-m <limit> set the limit in kilobytes for the available memory
-p <limit> set the maximum allowed number of passes
-s <file> dump symbolic information for debugging
$ diff mac_fasm2 mac_fasm3
$

Whew! Feel free to use my ideas or implementation.

Incidentally, using the above code in all libc versions wouldn't be bad. The 16 byte alignment won't terribly negatively effect non-Mac systems.

Yes, that's what I'm planning to do.