A simple application in Swift following the guidelines here: https://github.com/vandadnp/swift-weekly/blob/master/issue12/README.md to test how UASM behaves on OSX.
Tested in High-Sierra.
(http://www.atelierweb.com/a/osx.jpg)
Awesome! :)
I ran a bunch of basic tests on OSX while I was adding the Macho64 format support, but I'm sure there will be some bugs that crop up when it's really put through it's paces.
Quote from: johnsa on January 01, 2018, 03:21:25 AM
Awesome! :)
I ran a bunch of basic tests on OSX while I was adding the Macho64 format support, but I'm sure there will be some bugs that crop up when it's really put through it's paces.
May be there are some bugs, namely the usual ones related to alignment, I will check that out during 2018 for sure. :badgrin:
Luckily it uses the exact same proc/invoke handlers etc as Linux64 (so 2.46.6) should be up tomorrow with that other nix64 stack fix.
I was thinking there might be more issues around relocation entries on macho64 because the reference is extremely vague, and it's totally different from coff or elf so i had to sort of guess a bit by generating .o files on the mac with as and then trying to match the table entries one by one.
Shortly. I will try to make something a little more complicated and will see if it can handle that. :biggrin:
:) As long as you are prepared to help diagnose the macho format issue if it arises!! :)
(http://atelierweb.com/a/osx2.jpg)
_asmGetString:
0000000000000000 subq $0x8, %rsp
0000000000000004 leaq (%rip), %rax
000000000000000b addq $0x8, %rsp
000000000000000f retq
_asmTestStackAlignment:
0000000000000010 pushq %rbp
0000000000000011 movq %rsp, %rbp
0000000000000014 pushq %rbx
0000000000000015 subq $0x10, %rsp
0000000000000019 movq %rsp, %rax
000000000000001c addq $0x10, %rsp
0000000000000020 popq %rbx
0000000000000021 popq %rbp
0000000000000022 retq
_asmGetStack:
0000000000000023 subq $0x8, %rsp
0000000000000027 callq 0x10
000000000000002c addq $0x8, %rsp
0000000000000030 retq
Contents of (__DATA,__data) section
0000000000000031 48 65 6c 6c 6f 20 66 72 6f 6d 20 55 41 53 4d 21
0000000000000041 0a 00
I had no problems in passing a pointer to a string on the .data segment, as seen from ASM, to the application.
However, there is the stack alignment problem.
Probably the same stack alignment issue I've justed fixed for the Linux report, as it uses the same sysv handlers. I will send out 2.46.6 tonight and you can test it again. :)
Both these samples do not work properly with 2.46.6.
I could figure out the reasons except that the object files produced by the new release of UASM are much bigger.
The second sample does not even build, the error is:
ld: in section __TEXT,__text reloc 0: malformed mach-o, reloc addr 0x7 not in any atom file '/Users/jp/Documents/projects/mcuasm2/McUASM2/McUASM2/utest.o'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Ahh.. ok, now we find a relocation related problem. I've added __m128 etc as built-in types so those exist in the symbol table from the get-go so it must be those that are causing the issue.
However they shouldn't be included in the object file if they're not used so I'll look into it now.
2.46.7 update available. I've ensured the macho outputs are now consistent even with the new structures, it now passes the regression tests for this and both my osx1.asm and osx2.asm samples are identical and working.
Please test again with yours.
Thanks
John
Nope.
Undefined symbols for architecture x86_64:
"_asmAddMethod", referenced from:
-[UASMClass add:b:] in UASMClass.o
ld: symbol(s) not found for architecture x86_64
Undefined symbols for architecture x86_64:
"_asmGetStack", referenced from:
-[ObjcClass getStack] in ObjcClass.o
"_asmGetString", referenced from:
-[ObjcClass getString] in ObjcClass.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Ok, i've changed the exclusion of symbol entries to include symbols which are marked as public even if they're not used. OSX package updated, please try again.
Now, it works. :t
(http://www.atelierweb.com/a/osx3.jpg)
I have also added another proc to check how UASM deals with parameters passed in xmm registers. Deals well, knows that double_1 comes in xmm0, in Windows would be xmm2.
; result=(int)(((double)int_1+double_1^2)/(double)int_2)
_asmMixIntDouble proc int_1: qword, int_2 :qword, double_1:real8
cvtsi2sd xmm3, int_1
cvtsi2sd xmm4, int_2
movsd xmm5, double_1 ; double_1 is in xmm0. Different than Windows ABI
mulsd xmm5, double_1
addsd xmm3, xmm5
divsd xmm3, xmm4
cvtsd2si eax, xmm3
ret
_asmMixIntDouble endp
which disassembles to this:
_asmMixIntDouble:
31: 55 push rbp
32: 48 8b ec mov rbp, rsp
35: f2 48 0f 2a df cvtsi2sd xmm3, rdi
3a: f2 48 0f 2a e6 cvtsi2sd xmm4, rsi
3f: f2 0f 10 e8 movsd xmm5, xmm0
43: f2 0f 59 e8 mulsd xmm5, xmm0
47: f2 0f 58 dd addsd xmm3, xmm5
4b: f2 0f 5e dc divsd xmm3, xmm4
4f: f2 0f 2d c3 cvtsd2si eax, xmm3
53: 5d pop rbp
54: c3 ret
Quote
Ok, i've changed the exclusion of symbol entries to include symbols which are marked as public even if they're not used
They are used, but UASM has no way to know,
Great :)
Yeah I've set anything that is flagged as public or extern to be included in the symbol table in the .o file, even if it's not flagged as used, as one might assume it's intention is to be used from another object in the link phase.