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?
Don't do that. Do this instead:
(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 fromcrt1.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 withld
.However, consider what happens after your
main
returns. Normally, the code incrt1.o
will execute (equivalent of)exit(main(argc, argv));
. Since you linked withoutcrt1.o
, there is nobody to do that finalexit
for you, so the code returns to ... undefined location and promptly crashes.You also need to link the
crt1.o
(might have a different name, contains the necessary code up untilmain
can be called) and necessary libraries. GCC also usually needs to link tolibgcc.so
which contains necessary helper functions (for example, when doing 64 bit calculations on a 32 bit system) plus other system libraries. For example, on my Mac, it also needs to link tolibSystem
which also contain the usual C functions likeprintf
. On Linux, that's usuallylibc
.Note that your program cannot directly start with
main
(as you're trying to do with withld .. -e main
), the entry point needs to set up a few things prior to calling the C functionmain
. That's what the previously mentionedcrt1.o
is doing. I guess the segmentation fault is a result of this missing setup.To see what GCC is exactly doing on your system, call: