# How can I link a.out compiled by nasm?



## user0 (Apr 11, 2016)

nasm(1) works and spits out an object file in a.out format.
How can I link it into an executable on FreeBSD?

```
all: a.o
   gcc -ggdb -o a a.out
a.o: a.asm
   nasm a.asm -f aoutb -g -o a.out
clean:
   rm a.out a
```
gcc(1) does not recognize the format I have used in the Makefile:

```
make
nasm a.asm -f aoutb -g -o a.out
gcc -ggdb -o a a.out
a.out: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
*** Error code 1

Stop.
make: stopped in /usr/home/leo/Compile/asm/example1
```

There are some mentions of using ELF format, but why should I when a.out is the native format for BSD? http://www.int80h.org/bsdasm/


----------



## kpa (Apr 11, 2016)

Although the file is named a.out the native executable file format of FreeBSD is ELF, the transition from a.out to ELF format was done very very long ago 1). The convention of naming the default compiler output as a.out is an old UNIX standard and it was not changed even though the executable format was changed.


1) https://en.wikipedia.org/wiki/A.out


----------



## user0 (Apr 11, 2016)

I was able to compile into -f elf64, then link, but the program did not work.
It has Linux style subroutine calls with the params going into the registers. Do I need to switch to pushing the params onto stack?


----------



## SirDice (Apr 11, 2016)

Developer's Handbook: 11.3. System Calls


----------



## user0 (Apr 11, 2016)

Just out of curiosity: should not nasm produce and ld assume the machine's [default] executable format by default w/o options?
Why would a developer need to always specify the format? Isn't native compilation way more likely than cross?


----------



## kpa (Apr 11, 2016)

The system's linker does assume the ELF format always. The assembler you're using is ported third party software so it's a different story. You'll have to ask the port maintainer or the upstream maintainer of it why it does what it does.


----------



## jrigg (May 12, 2016)

user0 said:


> I
> It has Linux style subroutine calls with the params going into the registers. Do I need to switch to pushing the params onto stack?


Which parameters go in registers and which on the stack is dependent on CPU architecture.

For amd64:
http://www.x86-64.org/documentation/abi.pdf

For i386 the spec is different due to the smaller number of registers:
http://www.sco.com/developers/devspecs/abi386-4.pdf

EDIT: See correction below.


----------



## kpa (May 12, 2016)

Please read the developer's handbook article linked above, it clearly states that the parameters pushed on to stack -method is used for FreeBSD native code and the other method of using registers comes to play only when using the Linux emulation layer. The x86/x64 architecture offers more than one way of implementing subroutine calls and FreeBSD has chosen one way of doing it, Linux something else.


----------



## jrigg (May 12, 2016)

kpa said:


> Please read the developer's handbook article linked above, it clearly states that the parameters pushed on to stack -method is used for FreeBSD native code and the other method of using registers comes to play only when using the Linux emulation layer. The x86/x64 architecture offers more than one way of implementing subroutine calls and FreeBSD has chosen one way of doing it, Linux something else.


Thanks for the correction. Sorry if my reply caused confusion. My experience of assembly coding has mostly been on Linux amd64. 

The linked handbook article only shows i386. Does the same apply on amd64 (but with amd64 register names)?


----------

