OSDev.org

Posted: **Wed Jul 09, 2008 2:06 am**

Ok, fiddled some more with it and I definitely overwrite the memory where my string is located, but I don't know with what. Somehow changing the KERNEL_STACK address does not have an impact. I am absolutely unfamiliar with kernel loading and reserving memory for this, so does anybody have an idea how I can change the address space?
Cheers

Posted: **Wed Jul 09, 2008 2:35 am**

Decided to look a bit more and saw this:

Code: Select all

          kernel_entry:
                    mov     esp,     KERNEL_STACK

                    xor     ecx,     ecx
                    push     ecx
                    popf

                    push     eax
                    push     ebx
                    call     main

                    jmp     $
          }

Specifically:

Code: Select all

                    xor     ecx,     ecx
                    push     ecx
                    popf

Why are you clearing the flags?

I also would suggest removing the "call main" as a test to figure out if the right entry point is executing.

Posted: **Wed Jul 09, 2008 3:07 am**

I honestly got no idea why the flags are declared - as I said, I got the whole stuff from the http://ksrenevasan.blogspot.com/search?q=pe+kernel blog and just trusted that they know what they are doing, as I have absolutely no clue how to define a bootable header (just too old for that

)

Anyway, I've run the binary through a disassembler and all the entry points seem all right - changing the functions, or even putting the whole main function directly into the header does not change the behaviour.

I've tried other functions reading the memory and will always end up with the memory getting corrupted somewehere around 0x200c onwards (relative address, i.e. with the kernel binary starting at 0x000 (I've got no idea where it is put into memory during booting? 0x00101000 is that right? so 0x00101000+0x200c =
0x0010300c) If it's the stack building up exactly to this point, why does changing KERNEL_STACK have no effect?

Posted: **Wed Jul 09, 2008 3:47 am**

Ok. Try removing this code:

Code: Select all

                    xor     ecx,     ecx
                    push     ecx
                    popf

And see what happens.

I'll read that tutorial now and see how it all works to figure out why it's not working for you.

EDIT: The tutorial shows this code:

Code: Select all

void main(unsigned long magic, unsigned long addr)
{
          char *string = "Hello World!", *ch;
          unsigned short *vidmem = (unsigned short *) 0xB8000;
          int i;

          for(ch = string, i = 0; *ch; ch++, i++)
                    vidmem[i] = (unsigned char) *ch | 0x0700;
}

That doesn't seem to match up with your code - does the tutorial code work for you?

Posted: **Wed Jul 09, 2008 4:00 am**

Thanks a lot - I'll give it a try. Regarding the C code: I've tried different versions, including the one from the tutorial, all leading up to the same problem. As I said, I don't think it's the code itself, the content of the memory actually gets corrupted...

Update: removing the xor push pop part does not affect the behaviour

Posted: **Wed Jul 09, 2008 4:42 am**

could you please post a binary of your kernel and the intermediate files ? also, may it be a case of not including *(.rodata) / *(.rdata) in your linker script?

Posted: **Wed Jul 09, 2008 5:13 am**

Sure enough (see attached), note that I slightly changed the code to check different memory locations - current version looks like that:

Code: Select all

void main(unsigned long magic, unsigned long addr)
{
		  char *message1 = "Hello Simple Kernel World!";
		  char *message2 = "This is the Visual World calling!";
		  char *message3 = "Why does all my assembler crash?";

		  print(message2, 0);
		  print(message1, 80*2);
}

void print(char* message, unsigned long offs)
{
		  __asm
		  {
					mov ebx, offs
...

which is essentially identical...

Thanks for all your efforts

Posted: **Wed Jul 09, 2008 5:22 am**

In my personal opinion it'll be easier to shift all the text output stuff into a C function and let the compiler make the assembly code for you. Other than that, I have no idea what the problem is.

Posted: **Wed Jul 09, 2008 5:25 am**

Definitely easier, you're right and I started out with that too. I moved to Assembler only to see whether there is a memory management error in the compilation. But it turns out, the memory management is due to something else... (me, most likely

)

Posted: **Wed Jul 09, 2008 6:56 am**

Right, I fiddled some more with some success, i.e. it works, but I do not understand it fully

Code: Select all

                    dd(0x0010200F)               ; load_end_addr

Declares where the size of the data section indirectly: according to the original blog, the data section starts at 0x00102000 (why?) and hence the data size is 0xF - which is too small for the full string...

So if I increase load_end_addr and bss_end_addr
kernel.c:

Code: Select all

                    dd(0x0010201F)               ; load_end_addr	
                    dd(0x0010201F)               ; bss_end_addr

AND move the stack further down (again: why? it's not taking so much space, is it?)
kernel.h:

Code: Select all

#define KERNEL_STACK               0x00105fff

I can see my full string alright...

Is there any way I can move my data section BEHIND the stack?

Posted: **Wed Jul 09, 2008 7:24 am**

glad you've solved it

I believe you can tell the linker to put the data above the stack. I'm not sure what command line parameters are to make your linker do it, though.
It's pretty automatic with elf output format and a linker script.
With elf you no longer would need to tell the toolchain how much big the data is and you wouldn't need to put that in the multiboot header either.

Code: Select all

fragment from a linker script which makes your data load at 0x106000
.data 0x106000 {
*(.data)
*(.rodata) /* or rdata, depends on the toolchain if you need any of them*/
}

Just to make sure that your stack doesn't land where your code is you'd put your stack in a .bss section and add an appriopriate statement about .bss to the linker script.

Posted: **Wed Jul 09, 2008 8:01 am**

Your link phase that you posted created a map, called "kernel.map". You are probably supposed to get all those #define values out of that map, type them back into your code, and recompile one extra time. But that is probably the answer to most of your "why" questions. I don't think the CL linker allows linker scripts.

Posted: **Wed Jul 09, 2008 1:44 pm**

Thanks again for all your help

I haven't worked with elf yet, but I'll probably give it a try. As for the kernel.map, it's generated by Visual Studio and takes the links from the main code files - instead of cl I use link (see compile.bat)
Again, thanks a lot - I'm sure, I'll be back with more questions soon

Posted: **Wed Jul 09, 2008 8:28 pm**

Have you tried it in real hardware. Just to see if their is somthing with your computer that handel bochs and virtual machine what is should not ment to. just a suggestion. i test mine in real hardware so i now it works for real.

OSDev.org

Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner - something close to a solution

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner

Re: Bloody Beginner