Im just letting you know that I am currently debugging your kernel image to see if I can find the problem. I will post here and let you know if I find anything
Size limit???
Hey,
Im just letting you know that I am currently debugging your kernel image to see if I can find the problem. I will post here and let you know if I find anything
Im just letting you know that I am currently debugging your kernel image to see if I can find the problem. I will post here and let you know if I find anything
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Okay... This is what I have found so far:
The entire kernel is being loaded properly. I insured of this by checking the bytes of the loaded image from Bochs with a hex editor on the image file, all bytes checked match perfectly.
Somewhere in your kernel, an invalid jump is making RIP to be loaded an address. This address points to a data member (Byte offset 161) within the _IMAGE_OPTIONAL_HEADER structure of the file image, so it is going to attempt to execute your file header as executable code--which is a no no.
The bootloader works fine. Make sure that there is no stack curruption in your code. If there is, a RET instruction can easily pop an invalid value into RIP, causing this problem.
The entire kernel is being loaded properly. I insured of this by checking the bytes of the loaded image from Bochs with a hex editor on the image file, all bytes checked match perfectly.
Somewhere in your kernel, an invalid jump is making RIP to be loaded an address. This address points to a data member (Byte offset 161) within the _IMAGE_OPTIONAL_HEADER structure of the file image, so it is going to attempt to execute your file header as executable code--which is a no no.
The bootloader works fine. Make sure that there is no stack curruption in your code. If there is, a RET instruction can easily pop an invalid value into RIP, causing this problem.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
After reading what you wrote, I decided to step through with bochs to see what you meant, I watched very closely, and followed from the protected mode switch to the jmp that should load my kernel. What I noticed was that right after the jmp a whole bunch of
commands with some other apparently random commands were running. I stepped through those and found where mainCRTstartup begins. I have only seen my kernel run and so I don't know if this is normal or not, but given my errors I would assume that this is inside the _OPTIONAL_HEADER_ and that when the size of my kernel differs the different junk in here is what is causing the problem. The memory address shown when I finally get the cli from mainCRTstartup is 0x00100400. If I understand you correctly, then I should be able to edit my stage2 code to jmp to that location and it should work. I am going to try it and see what happens but if the size of this changes then I don't know what to do. I will post what the result is after I have done it. thanks for help.
EDIT: well, I jimmy rigged it but it seems to have paid off. I am now running with a 13.5k kernel and it is working. I now just have to get paging working but that is a totally separate issue. thanks again
Code: Select all
add byte ptr ds:[eax], al
EDIT: well, I jimmy rigged it but it seems to have paid off. I am now running with a 13.5k kernel and it is working. I now just have to get paging working but that is a totally separate issue. thanks again
Getting back in the game.
Nice to hear it is working
You can setup MSVC++ so that mainCRTStartup() is guaranteed to be at the expected entry point address. This way, you do not need to go back and modify the address each time.
Let me know if you want it, or not.
(I will see if I can update that tutorial this weekend with this information as well.)
You can setup MSVC++ so that mainCRTStartup() is guaranteed to be at the expected entry point address. This way, you do not need to go back and modify the address each time.
Let me know if you want it, or not.
(I will see if I can update that tutorial this weekend with this information as well.)
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Go to Project Properties->Linker->Advanced.
Set Entry Point to mainCRTStartup, or whatever your entry library routine is for your kernel.
Set Base Address to 1 MB (0x100000)
All of this may already be set. The following may be new:
Create a new standard text file (Lets call it Order.txt). Type the function names in order of how you want them to be linked. For example, if mainCRTStartup() is the entry routine, and kmain() is your main() routine, this will work:
You do not need to add any more routines. This will tell MSVC++ to link mainCRTStartup() at the base address (1MB), followed by kmain(). All other code and data will be placed to locations above kmain(), so you never need to edit this file unless you want to.
Now, back in MSVC++ Linker Optimization section...
Under Function Order, type in the location of your file (For example, Order.txt)
This should resolve that problem, and insure mainCRTStartup() is always at the base address of 1 MB.
Set Entry Point to mainCRTStartup, or whatever your entry library routine is for your kernel.
Set Base Address to 1 MB (0x100000)
All of this may already be set. The following may be new:
Create a new standard text file (Lets call it Order.txt). Type the function names in order of how you want them to be linked. For example, if mainCRTStartup() is the entry routine, and kmain() is your main() routine, this will work:
Code: Select all
mainCRTStartup
kmain
Now, back in MSVC++ Linker Optimization section...
Under Function Order, type in the location of your file (For example, Order.txt)
This should resolve that problem, and insure mainCRTStartup() is always at the base address of 1 MB.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}