OSDev.org

Hello im currently trying to link my kernel loader written in asm to my C kernel...
heres some code: the problem is when i link them together ld outputs a bin file with the linked code with MZ and dos headers...
i want ld tomake a flat binary without any headers just an normal bin as nasm will ouput..
thanks for any help.

make.bat:

Mtype2 wrote:Hello im currently trying to link my kernel loader written in asm to my C kernel...
heres some code:

Code: Select all

[BITS 32]
extern _sys_entry
global x32
x32:
	mov		ax, data		; set data segments to data selector (0x10)
	mov		ds, ax
	mov		fs, ax
	mov		es, ax
	mov		gs, ax
	mov		esp, 90000h	
	call 	_sys_entry
	hlt


times 512-($-$$) db 0

Code: Select all

void sys_entry(void)
{
	writeLine("Kernel Loaded");
}

the problem is when i link them together ld outputs a bin file with the linked code with MZ and dos headers...
i want ld tomake a flat binary without any headers just an normal bin as nasm will ouput..
thanks for any help.

make.bat:

Code: Select all

call nasm source/BOOTZ.asm -f bin -o bin/BOOTZ.bin
call cd bin
call gcc -ffreestanding -fno-builtin -nostdlib -c C:\Users\Mark\Desktop\OS\source\kernel\*.c
call cd..

call nasm -f elf source/CORELD.asm -o bin/CORELD.o

call ld -Ttext 0x1000 -o bin/CORE.bin bin/*.o

"call nasm -f elf source/CORELD.asm -o bin/CORELD.o"

Shouldn't that say "nasm -f bin"? You told it to use ELF that's why you are seeing the headers. Unless you wanted elf...

- Matt

i have already tried that...ld says that... File format not recognized.
maybe you misunderstood me...

im compiling CORELD.asm into an object file.
after its compiled i feed it to ld inorder to link it with kernel.o and terminal.o
but unfortunately i get the MZ header and an ugly formatted bin file that messes all my adresses.

Mtype2 wrote:i have already tried that...ld says that... File format not recognized.
maybe you misunderstood me...

im compiling CORELD.asm into an object file.
after its compiled i feed it to ld inorder to link it with kernel.o and terminal.o
but unfortunately i get the MZ header and an ugly formatted bin file that messes all my adresses.

Perhaps I did, but lets take a look at something.

"call nasm -f elf source/CORELD.asm -o bin/CORELD.o"
Here you compile CORELD.asm to CORELD.o in the bin directory as an "ELF" Binary.

"call ld -Ttext 0x1000 -o bin/CORE.bin bin/*.o"
Here you use LD which I assume is a linking tool of some sort which uses a wild card in the directory "bin" with card ".o". What file lies in there? Oh just the ELF binary file "CORELD.o". That lies your issue, if you are getting headers that are messing up your addresses, then either two things are happening:

1. You don't want the elf format and because you are using it you are getting headers.
or
2. You want the elf format and I am misunderstanding this altogether and there is a problem somewhere else.

Now I'm not 100% what you are trying to accomplish thus this is hard for me to help solve your problem, also considering I don't use LD so perhaps maybe someone else knows whats wrong. Either way good luck.
Cheers

...
the *.o means "input all the objects in the specified directory."
in the bin folder i have CORELD.O TERMINAL.O KERNEL.O
so when i'm calling LD it links all the three files just fine... i can confirm that by looking at the linked bin file with a hex editor and suddenly finding a string which i declared in KERNEL.O
so.. the linking process goes as supposed (kinda)...

however, the problem is that i get mz headers,gcc coments,and some other irrelevant stuff inside my final bin file,so when its loaded i cant jump to it cuz the offsets are messed(or the mz code isnt readable... :/ )[its loaded by stage0 from the disk to 0x1000]

whats the correct way of linking the kernel with the loader?
are there any alternatives? with examples please
thanks

Mtype2 wrote: ...
the *.o means "input all the objects in the specified directory."
in the bin folder i have CORELD.O TERMINAL.O KERNEL.O
so when i'm calling LD it links all the three files just fine... i can confirm that by looking at the linked bin file with a hex editor and suddenly finding a string which i declared in KERNEL.O
so.. the linking process goes as supposed (kinda)...

however, the problem is that i get mz headers,gcc coments,and some other irrelevant stuff inside my final bin file,so when its loaded i cant jump to it cuz the offsets are messed(or the mz code isnt readable... :/ )[its loaded by stage0 from the disk to 0x1000]

whats the correct way of linking the kernel with the loader?
are there any alternatives? with examples please
thanks

Ok so we are both on the same page From what I've read, never done this, but you need to strip the unwanted headers from the input files.. I forget what the tool is, but that's what you'll need to do. Sorry if that's an unhelpful answer, but at least it will get you in the right direction.

- Matt

Anybody? it seems to be funny to stuck at linking stage when its the only barrier between you and programming something decent in the OS

Use the "--oformat=binary" swtch in the ld command.

Posting Checklist. I don't trust that ld. I certainly don't trust the place where you got the linker command from. Positioned binaries should always be made using a linker script.

OK. i have succesfully made a binary from the loader and the kernel and the boot0 jumps to the loader with no problems... untill i call my _sys_entry c func from pmode... i get the following error:

write virtual checks:no write acess to seg...
add byte ptr ds:[eax] , al:0000

and a BXVGA panic !?

whats wrong?

build:

The error message seems fairly clear but, without seeing your GDT and IDT or your writeLine function, it's just guesswork. Ckeck your segment selectors. And I would advise you to learn how to use a debugger to help you trace errors.

You are at a fairly simple stage at the moment and if you don't learn how to deal with simple errors by yourself you are going to be really lost when things get more complicated.

Mtype2 wrote:whats wrong?

Code: Select all

call gcc

Did you read the posting checklist yet? We can't help you properly until you set up a real cross-compiler.

The error message from Bochs suggests a problem with your bootloader. Did you finish fixing it yet?

BTW, you do realise you don't have to put "call" in front of everything in a batch file, right? The only time it's needed is when you're running another batch file...

thats the loader code... the gdt is fine cuz it works as expected without the jmp sysentry...
registers are:
CS=0008
DS=0010
SS=1000//CANT FIX IT
ES=0010
FS=0010
GS=0010

as you can see im offsetting 0x10000 to each segment and the gdt

oh..lol... i actually didnt read enough sectors...my image is 21kb in size and i read only 2 sectors..changed it to 45 and voilla..it works... gonna buy some greygoose and celebrate thanks for help anyway