Hacker News new | ask | show | jobs
by andy_threos_io 1986 days ago
Prime example of how you NOT write assembly code, no matter what cpu are you using.

First thing first, macro assemblers have been around for at least 40+ years. So don't use numbers in your code. use macros or defines.

Ex. you can compile with gcc flags -x assembler-with-cpp

and you can have nice defines in your code.

Second on a decent OS even in assembly link against operating system call library, no matter what. The system call numbers can change. so use symbols.

Also don't write the string length in the code, it's total lame.

and use .asciz not .ascii

and define your function symbols to function gcc:

    .global my_func_name
    .type my_func_name, function
    my_func_name:
if you use C preprocessor for assembly compile just make an include like this:

  #define _FUNCTION(A) .global A ;\
   .type A, function
EDIT: For the not well informed HN readers:

https://developer.apple.com/library/archive/qa/qa1118/_index...

"Apple does not support statically linked binaries on Mac OS X. A statically linked binary assumes binary compatibility at the kernel system call interface, and we do not make any guarantees on that front. Rather, we strive to ensure binary compatibility in each dynamically linked system library and framework."

So DON'T write direct system call numbers in your code!

2 comments

> Ex. you can compile with gcc flags -x assembler-with-cpp

You don't even need the flag. Just use the .S file extension rather than .s

Using .ascii is fine; the string is going to a syscall–not libc. And using the standard library in a program like this is kind of beside the point…
nope, every decent OS has system call library you can write like:

  bl _Open ; whatever syscall name you have
and the linker or the OS dynamic linker will get you the proper system call code, with the numbers.

BTW even in our small threos.io os we use dynamic linked system calls.

I know how dynamic linkers work and am not arguing against using the libc interface in general. I'm saying that this program intentionally doesn't use those interfaces.
This can be a problem on macOS; Apple doesn't keep compatibility among releases at sysenter level.

Golang used to run into this, they switched to using libSystem in 1.11: https://golang.org/doc/go1.11#runtime

The system call library is NOT libc.
Then Apple doesn't have it.
/usr/lib/system/libsystem_kernel.dylib
you don't know about it

/usr/lib/system/libsystem_kernel.dylib

ex. https://stackoverflow.com/questions/37656016/osx-setgid-syst...

That's part of libSystem, macOS's libc implementation…