Can't link c-kernel with asm starting code

[sysfree]

My simple os consists of 2 files: start.asm and kernel.c.  start.asm initializes GDT, and then calls main() in kernel.c. When i link them together and boot with it, it crashes.  But if i dont use the c file and compile the start.asm as binary and boot with it, it's OK. whats wrong? (btw, i boot my kernel with my boot-loader.)
The main() function does nothing than a "return".
I link them with ld:
kernel:start.o kernel.o
       ld -o kernel  --oformat binary  -Ttext 0x1000 start.o kernel.o
start.o:start.asm
       nasm -f aout -o start.o start.asm
kernel.o:kernel.c
       gcc -c -o kernel.o kernel.c

[roswell]

Hi,

You must be sure that when you link your kernel, each segment is written where it is supposed to be.

So I can suggest 2 things :
1 ) Print out a symbol map by adding this option to ld
-Map symbolsmap.txt
With the symbols map you will check that everything is OK.

2 ) Use a linker script to tell ld what to do. Here is mine :
OUTPUT_FORMAT( binary )

SECTIONS
{
. =1*1024*1024;
.text :{ multiboot/multiboot_asm.o(.text) ; objects/*.o(.text) }
.data ALIGN(8) :{ objects/*.o(.data) }
kernelend = ALIGN(8);
.bss ALIGN(8) :{ objects/*.o(.bss) objects/*.o(COMMON) }
. = ALIGN(8);
bssend =  .;
}


I hope this will help you.

Roswell

[roswell]

Sorry, it transformed 8 and )  to smiley. Please correct it.

Roswell

[bchadwick]

I had the same trouble a little while ago. And I still can't return from main, but....
Try putting a loop in main, just to hang like...
  here: goto here
in my case, the problem was the setup of the stack. That could also have something to do with it. Main() uses the stack for initial variables when it's called (at least that's what DJGPP did).  If it's not set right, you'll get a double fault, when the when the thrown exception tries to use the stack to push the current state.
 hope some of that will help.
BC
 
 

[sysfree]

thanks for your reply! I've resolved the problem by reorgnizing my source code. I put the GDT initializing code into the boodloader, and it's OK. Maybe it's because of the fault of the GDT table, or the reallocation of LD, i'm not sure. But it doesn't matter now.