Quantcast
Channel: Active questions tagged gcc - Stack Overflow
Viewing all articles
Browse latest Browse all 22077

Linking NASM generated object file (x86_64) with ld : binary file causes segmentation fault [duplicate]

$
0
0

This question already has an answer here:

I have an a.asm file which goes like this:

    section .text
    global  _start  
_start:
    push    rbp         ; save rbp
    mov     rbp, rsp    ; rbp is caller's stack

    mov     rsp, rbp    ; restore caller's stack frame
    pop     rbp
    mov     rax, 0
    ret                 ; TODO: remove segmentation fault

Invoking nasm with nasm -f elf64 -o a.o a.asm, and then linking the .o file by invoking ld -o a a.o results in an executable which causes segmentation fault.

What I was trying to do? Initially the last invocation was gcc -m64 -o a a.o (with an .asm file having the entry symbol renamed to main rather than _start, because ld does not recognize main as a start symbol), and the output file was taking quite a lot of space. I am not exactly sure what gcc does behind the door, the gcc-generated output file runs normally.

  • What is the difference between gcc-generated executable files and ld-generated executable files?
  • How to make an executable out of this .asm which is as relatively leaner than a gcc-generated executable and does not segfault? (EDIT: @Jester comments that we should use an exit syscall for returning. Linux 64-bit x86 64 Assembly Exit Syscall Number is 60. The ret operation should be replaced by the following code. Details can be found here.)
    mov     rax, 60     ; syscall 60 is sys_exit
    xor     rdi, rdi    ; set exit status to 0
    syscall
  • Would you like to suggest some online resources which discusses gcc-ld assembling-linking procedure in more detail? I have a lack of understanding how assembly and linking works.

Viewing all articles
Browse latest Browse all 22077

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>