flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Unix > MacOS X

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
narada



Joined: 15 Feb 2008
Posts: 77
Location: Ukraine, Dnepropetrovsk
MacOS X
is Mac OS X syscalls == BSD ??? (needed fiest 10-20 calls for wr/rd/...)

_________________
http://www.omegicus.com
Post 21 Mar 2009, 10:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
narada



Joined: 15 Feb 2008
Posts: 77
Location: Ukraine, Dnepropetrovsk
Томас Гриштар, товарисч, шо там у нас с MacOS???
Post 22 Mar 2009, 14:27
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
narada



Joined: 15 Feb 2008
Posts: 77
Location: Ukraine, Dnepropetrovsk
funny... ))) so many replies)))

but I already finded... i think))) NeXTStep - is from BSD tree... so... ))
Post 23 Mar 2009, 20:07
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
drhowarddrfine



Joined: 10 Jul 2007
Posts: 538
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.
Post 23 Mar 2009, 21:12
View user's profile Send private message Reply with quote
Christophe Lavarenne



Joined: 25 Aug 2009
Posts: 5
Location: Burgundy - France
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.
Post 25 Aug 2009, 12:33
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5479
Location: Kraków, Poland

Christophe Lavarenne wrote:
Grysztar, will you have an opportunity to port fasm to Mac OS X ?


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).
Post 25 Aug 2009, 13:01
View user's profile Send private message Visit poster's website Reply with quote
echd



Joined: 01 Jul 2009
Posts: 1
Location: Palmetto, GA USA
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
Post 05 Sep 2009, 00:40
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 1953
Location: Usono (aka, USA)
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. Sad
Post 20 Sep 2009, 22:19
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5479
Location: Kraków, Poland
Not having a machine for test was just a lame excuse. Wink
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?
Post 20 Sep 2009, 22:36
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 1953
Location: Usono (aka, USA)
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).
Post 20 Sep 2009, 22:52
View user's profile Send private message Visit poster's website Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 23
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
Post 09 Oct 2009, 23:35
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 23
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
Post 10 Oct 2009, 00:11
View user's profile Send private message Reply with quote
rthelen



Joined: 20 Oct 2009
Posts: 5
Location: California
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.
Post 20 Oct 2009, 06:57
View user's profile Send private message Visit poster's website Reply with quote
rthelen



Joined: 20 Oct 2009
Posts: 5
Location: California
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?
Post 20 Oct 2009, 07:20
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5479
Location: Kraków, Poland
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".
Post 20 Oct 2009, 08:29
View user's profile Send private message Visit poster's website Reply with quote
rthelen



Joined: 20 Oct 2009
Posts: 5
Location: California
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!


Last edited by rthelen on 20 Oct 2009, 17:54; edited 1 time in total
Post 20 Oct 2009, 15:54
View user's profile Send private message Visit poster's website Reply with quote
narada



Joined: 15 Feb 2008
Posts: 77
Location: Ukraine, Dnepropetrovsk
Why do not try Emulator of x86/PPC ???
Post 20 Oct 2009, 16:07
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
rthelen



Joined: 20 Oct 2009
Posts: 5
Location: California
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. Smile

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.
Post 20 Oct 2009, 17:53
View user's profile Send private message Visit poster's website Reply with quote
rthelen



Joined: 20 Oct 2009
Posts: 5
Location: California
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/

Code:
--- fasm-orig/source/libc/fasm.asm        2009-07-06 06:44:06.000000000 -0700
+++ fasm-mac/source/libc/fasm.asm        2009-10-20 15:21:41.000000000 -0700
@@ -10,12 +10,19 @@
  { common
     local size
     size = 0
-   reverse
-    pushd arg
-    size = size+4
-   common
+    mov ebpesp
+   if ~ arg eq
+    reverse size = size+4
+    common add esp, -size
+   end if
+    and esp, -16
+   if ~ arg eq
+    add espsize
+    reverse pushd arg
+    common
+   end if
     call proc
-    add esp,size }
+    mov espebp }
 
 extrn gettimeofday
 


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

Code:
--- fasm-orig/source/libc/system.inc       2009-07-06 06:44:06.000000000 -0700
+++ fasm-mac/source/libc/system.inc      2009-10-20 14:54:17.000000000 -0700
@@ -45,7 +45,7 @@
    movzx   eax,al
      push    eax
         ccall   free,[additional_memory]
-   call    exit
+       ccall   exit
        mov     esp,[stack_frame]
   pop     ebp
         ret



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.
Post 20 Oct 2009, 22:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5479
Location: Kraków, Poland

rthelen wrote:
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.
Post 20 Oct 2009, 23:19
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2013, Tomasz Grysztar.