cross-compiler question

[Gman]

I successfully made a bootloader, and am to the point where I am developing my kernel. I know I need a cross-compiler, but I don't know what target to make it in. I have made a cross-compiler before so I know how to make one. After I tried with one type but, make directed me to a file with the targets in it, but it didn't help. I need the format to be a flat binary, but none of the formats were binary, the closes was msdos, but I dont think that will do it. I can work on either linux, or windows, but I am more familiar with windows.
Thanks

[gerryg400]

My suggestion, for what it's worth, is to target an ELF executable. Then use an extra step after LD to convert your ELF file into a flat binary. I think objcopy does this ?? (I intended to do this but in the end incorporated the ELF to binary converter into my loader.)

The reason is that when your OS is up and running you can use the same tool chain to build your ELF format application executables. Just my thoughts.

[Gman]

Thanks, Do you know of any good tutorials for ld linker scripts?

[gerryg400]

The wiki and the LD docs are the only ones I've ever looked at. My linker script is trivial though. There are also some examples like this in the barebones tutorials.

[Gman]

Ok, a linker script looks pretty easy, but I have one more question. In the section SECTIONS, would I set my .text section at 0 because it is a binary file, or at 0x100000 because that is where the file will be loaded in memory.

[gerryg400]

would I set my .text section at 0 because it is a binary file, or at 0x100000 because that is where the file will be loaded in memory.

You set it to the address it will execute at. That may not be the same as the load address depending on paging (virtual memory)

My linker script used to have something like this

Code: Select all

	.text 0xc0100000 : 
	  AT ( 0x100000 ) ALIGN (0x1000)
	  { *(.text) } 

Grub loaded it at 0x100000 and it mapped itself to 0xc0100000 for execution

[Gman]

Ok, I'm not using paging, so since it will be executed at 0x100000 my .text section should be set to 0x100000, right?

[TylerH]

As long as you're using a flat memory model, yes. That means the base addr in your code segment needs to be 0.

[gerryg400]

Ok, I'm not using paging, so since it will be executed at 0x100000 my .text section should be set to 0x100000, right?

Yes, you don't need the AT statement unless you have virtual memory.

[Gman]

Thanks for the help, the script I made worked, kinda. I am to the point of printing strings, and I was curious if the problem was in my linker script or in my function.
link.ld:

Code: Select all

OUTPUT_FORMAT("binary")
OUTPUT(kernel.bin)

SECTIONS {
	
	.text :  {
		*(.text)
	}
	.data :  {
		*(.data)
		*(.rodata)
	}
	.bss :  {
		*(.bss)
	}
}
	

printStr:

Code: Select all

void printStr(u8 *c){
	u16 i = 0;
	while(c[i]!='\0'){
		printChar(c[i++]);
	}
}

When I read the kernel binary with a hex editor I can see the string I am trying to print, but it is at the very end. So I don't think the problem is my linker script.

[gerryg400]

It's more usual to put rodata in the text segment. But I'm not sure whether that's the problem.

[Gman]

I put rodata in text, and it didn't display anything at all. when I put it in data It prints S . Incase your wondering the string I'm printing is HELLO WORLD.
I also found that It isn't my C function, becuase I just tried the one from Jamesm's tutorial, and the result was the same.

[gerryg400]

Use objdump to look in your binary and check that the correct string address is being pushed on the stack to be passed to your c function. Someone had a similar problem recently.

[Gman]

When I try to use objdump It gives an error about the file format not recognized. Is this becuase the cross-compiler is build for elf files? I tried using bochs debbuger, but It was hard to tell when the file was being loaded.

[gerryg400]

Did you build binutils ? I would have thought that if objdump and ld were built together they should be compatable. Oh and you'll need to do an objdump --target=binary or something.