srvaldez wrote:I know that the Mac is not a supported platform but naked functions fail...
the main program calls a decorated function whereas the naked function was not decorated.
btw, it works ok on windows and linux
I noticed that bug and and a pile of other OSX ones and fixed it, but I haven't submitted a pull request yet. You can try it though
I spent several days trying to get -gen gas to work on OSX. Well, I got it working fine... unfortunately you can't actually use it, because Apple gas is broken. It has a major bug where if you ever refer to the same label twice in intel-syntax code or do a backwards jmp/call, it gives the error:
Code: Select all
fb_naked_asm.asm:33:suffix or operands invalid for `call'
This bug has been known for two decades, but Apple don't care about such things, and their rate of development for these core utilities is <1% of GNU's binutils anyway. I tried to fix it myself, but the gas source is the stuff of nightmares. I gave up on even getting FSF gas to compile after a few hours and can't tell if it even properly supports Mach-O, but it didn't a few years ago. I also tried LLVM's assembler, but it turns out its support for intel syntax is utterly broken... they did fix the most serious bug a few days ago though; haven't tried it since. There are no other assemblers supporting intel syntax for mach-o, unless you want to produce an ELF object file and convert to mach-o with objconv.
srvaldez wrote:here's the first example adapted for the Mac
Hey wait... are you saying that that code works for you? It doesn't assemble for me:
Code: Select all
fb_asm.c:26:suffix or operands invalid for `js'
fb_asm.c:38:suffix or operands invalid for `jmp'
fb_asm.c:42:suffix or operands invalid for `jmp'
That is, it hits the Apple gas bug I just mentioned. So you seem to have a working assembler, which I tried so hard and failed to find!
Can you please tell me where you got your build system (XCode, macports, homebrew?) and its version, and the OSX and gas versions (as -version)?
Edit: I'm not sure the above code is handling the stack correctly, even though the app runs OK even with -O 3. I need to determine if pushing/popping a 64-bit register changes the stack pointer by 8 bytes or 16 bytes.
Maybe you are referring to the existence of x86 instructions that push/pop a 16bit value on the stack to a 32 bit register and vice versa. There are no other mismatched-size push/pop instructions for other bitwidths.