I am having trouble linking 2 object files one of which was generated from an Assembly Language Source File and another that was generated from a C Source file.
C source code:
//main2.c
extern int strlength(char *);
int main(){
char * test = "hello";
int num = strlength(test);
return num;
}
Assembly source code:
#strlength.s
.include "Linux32.s"
.section .text
.globl strlength
.type strlength, @function
strlength:
pushl %ebp
movl %esp, %ebp
movl $0, %ecx
movl 8(%ebp), %edx
read_next_byte:
movb (%edx), %al
cmpb $END_OF_FILE, %al
jle end
incl %edx
incl %ecx
jmp read_next_byte
end:
movl %ecx, %eax
popl %ebp
ret
When I compile and run using 'gcc' like this:
gcc main2.c strlength.s -m32 -o test
./test
echo $?
I get 5 which is correct. However when I compile/assemble separately and then link with 'ld' like this:
as strlength.s --32 -o strlength.o
cc main2.c -m32 -o main2.o
ld -melf_i386 -e main main2.o strlength.o -o test
./test
I get a segmentation fault. What is causing this? Am I not following the C calling convention 100% correctly?
ld -melf_i386 -e main main2.o strlength.o -o test
Don't do that. Do this instead:
gcc -m32 main2.o strlength.o -o test
(You should probably not call your test exectuable test
, as it may conflict with the /bin/test
, standard on most UNIX systems.)
Explanation: UNIX binaries do not generally start executing at main
. They start executing in a function called _start
, which comes from crt1.o
or similar ("C Runtime startup"). That file is part of libc, and it arranges for various initializations, required for the proper start up of your application.
Your program actually doesn't require anything from libc
, which is why you were able to link it with ld
.
However, consider what happens after your main
returns. Normally, the code in crt1.o
will execute (equivalent of) exit(main(argc, argv));
. Since you linked without crt1.o
, there is nobody to do that final exit
for you, so the code returns to ... undefined location and promptly crashes.