Page 3 of 3
Re:So I switch into Pmode and I call my kernel when
Posted: Thu Aug 24, 2006 11:16 pm
by Candy
REV wrote:
==This is my GDT==
[tt]
gdt: ;This is a pointer. Its value will be help calculate its size
gdt_null: ;Null Segment
dw 0 ;Fill it up with 0s
dw 0 ;More 0s
db 0
db 0
db 0
db 0
gdt_code: ;Our code segment will be defined here
;First Double word
dw 0FFFFh ;Make this 4GB in size
dw 0 ;The first 16-bits of the base address
;Second Double Word
db 0 ;Bits 16-23 of the base address
db 10011010b ;Present = 1 Privilage = 0 Code = 1 CF = 0 Readable = 1 AF = 0
db 11001111b ;Granularity = 1 Size = 1 Reserved = 0 ASP = 0 Limit = 4GB
db 0 ;Last 24-31 of base address
gdt_data: ;Our data segment will be defined here
;First Double word
dw 0FFFFh ;Make this 4GB in size
dw 0 ;The first 16-bits of the base address
;Second Double Word
db 0 ;Bits 16-23 of the base address
db 10010010b ;Present = 1 Privilage = 0 Code = 0 CF = 0 Readable = 1 AF = 0
db 11001111b ;Granularity = 1 Size = 1 Reserved = 0 ASP = 0 Limit = 4GB
db 0 ;Last 24-31 of base address
[/tt]
==This is the kernel code==
All my assembly code is:
[tt]
[extern main_] ;NASM directive for the C function main()
SECTION .text USE32 ;NASM directive for code
[bits 32] ;NASM directive to use 32-bit instructions
call main_ ;Call the C/C++ code
cli ;Disable interrupts
hlt ;Halt the CPU
[/tt]
This is my C/C++ code:
[tt]
unsigned char *text = (char *)0xB80000;
void main();
void main() {
*text++ = '!';
*text++ = 7;
while(1) { }
}
[/tt]
That's a 0 too much in your video address there.
You might still accept interrupts, since you don't disable them explicitly.
What about disassembling your intermediates, or tracing in bochs from the breakpoint at the start of your code? The first would show you whether NASM understood it and the second would show you what JLOC made of it. A hexdump of the image will be quite clear too.
Re:So I switch into Pmode and I call my kernel when
Posted: Fri Aug 25, 2006 9:53 am
by REV
I have a lot more code done I just "cut it out" to help diagnose the problem.
Here is the hex dump of my kernel:
[tt]
00000000 FA E8 02 00 00 00 FA F4 68 08 00 00 00 E8 ED FF ??....??h....???
00000010 FE FF 52 A1 37 00 00 00 8D 50 01 89 15 37 00 00 ??R?7...?P.?.7..
00000020 00 C6 00 21 A1 37 00 00 00 8D 50 01 89 15 37 00 .?.!?7...?P.?.7.
00000030 00 00 C6 00 07 EB FE 00 80 0B 00 ..?..??.?..
[/tt]
Re:So I switch into Pmode and I call my kernel when
Posted: Fri Aug 25, 2006 1:12 pm
by Ryu
Heres what it disassembles to:
Code: Select all
seg000:00010000 seg000 segment byte public 'CODE' use32
seg000:00010000 assume cs:seg000
seg000:00010000 ;org 10000h
seg000:00010000 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:00010000 cli
seg000:00010001 call sub_10008
seg000:00010006 cli
seg000:00010007 hlt
seg000:00010008
seg000:00010008 sub_10008 proc near ; CODE XREF: seg000:00010001p
seg000:00010008 push 8
seg000:0001000D call near ptr 0FFFFFFFFh
seg000:00010012 push edx
seg000:00010013 mov eax, large ds:37h
seg000:00010018 lea edx, [eax+1]
seg000:0001001B mov large ds:37h, edx
seg000:00010021 mov byte ptr [eax], 21h ; '!'
seg000:00010024 mov eax, large ds:37h
seg000:00010029 lea edx, [eax+1]
seg000:0001002C mov large ds:37h, edx
seg000:00010032 mov byte ptr [eax], 7
seg000:00010035
seg000:00010035 loc_10035: ; CODE XREF: sub_10008+2Dj
seg000:00010035 jmp short loc_10035
seg000:00010035 sub_10008 endp
is the problem, which doesn't relate to your source code. My only guess is made by watcom. I have some questions concerning watcom.. is there a "release" and "debug" compilation modes? If so which mode did you compile under? And, can you tell watcom to not use the default CRT libraries?
Oh yes.. the global: unsigned char *text = (char *)0xB80000; which could be why theres a call to initialize globals, and the code segment it runs in might have been disgarded during linkage.
Re:So I switch into Pmode and I call my kernel when
Posted: Fri Aug 25, 2006 2:31 pm
by REV
Well I am using 11.0c. Its a release version. Thats cause Im too lazy to upgrade to Open Watcom 1.3 ;D
Looking at Wcc386 there are some command line perimaters that look intresting:
[tt]
-hc generate Codeview debugging information
-hd generate DWARF debugging information
-hw generate Watcom debugging information
[/tt]
Im compiling I guess under the release mode. The default librarys I don't belive are being compiled. Just to make sure I renamed the include and library directories
Ive also disabled all the compiler "extensions" so its compiling by the ANSI standard.
Well Im going to go over the documentation. But this still seems a little weird to me.
Re:So I switch into Pmode and I call my kernel when
Posted: Sat Aug 26, 2006 3:30 pm
by REV
>:(
Should I upgrade to Open Watcom 1.3 then?
Re:So I switch into Pmode and I call my kernel when
Posted: Sun Aug 27, 2006 6:27 am
by Candy
I'm just going to guess that the compiler inserted some form of call to some function at that point, which you don't have defined. It then defined the function arbitrarily to be at -1 (or 0xFFFFFFFF) and caused your program to jump to EIP=-1. This then wrapped around to run the IVT, which contained invalid code.
I'm guessing the function is called alloca(). Try defining it and see whether you get more sensible results. Next time, disassemble first or get a compiler you trust and understand.
Re:So I switch into Pmode and I call my kernel when
Posted: Tue Aug 29, 2006 11:13 am
by REV
I fixed it.
I had to turn off Stack Overflow checking. Which dosn't sound too good
Now Its time to work on my kernel.
Hmm how come nothings getting printed?
[tt]
unsigned char *textaddress = (char *)0xB8000;
void main();
void main() {
while(1) {
*textaddress++ = '!';
*textaddress++ = 7;
}
}
[/tt]
Re:So I switch into Pmode and I call my kernel when
Posted: Tue Aug 29, 2006 11:40 am
by Candy
REV wrote:
I had to turn off Stack Overflow checking. Which dosn't sound too good
Time for a proper quote on the compiler:
If you make something that an idiot can use, only an idiot will want to use it.
Don't call functions unless I'm !#*()& telling you to.
Now Its time to work on my kernel.
Hmm how come nothings getting printed?
[tt]
unsigned char *textaddress = (char *)0xB8000;
void main();
void main() {
while(1) {
*textaddress++ = '!';
*textaddress++ = 7;
}
}
[/tt]
Did you properly link in the variable? Did you map the memory correctly? Do your segments work? Did you trace it in bochs to see what it did?
Re:So I switch into Pmode and I call my kernel when
Posted: Tue Aug 29, 2006 12:05 pm
by REV
All my segments work I belive. All these are in the same source file. I belive the memory is mapped correctly. (What do you mean by correctly?) Let me check Bochs aaaaannnnnd it dosn't tell me anything.
Re:So I switch into Pmode and I call my kernel when
Posted: Tue Aug 29, 2006 3:57 pm
by Combuster
by testing in bochs he means using the bochs debugger to see where and if your characters are being printed to. Bochs' debugger can tell you where memory is mapped to in case you use paging, and to see where your segments are directing your memory accesses to. Just set a breakpoint for 0x7c00 and enjoy reading the rest of the bochs manual
Right now i'm expecting bochs (without debugger) to either ignore your attempts or flood warnings since you'll be running off the end of video memory straight into the bios region with this loop...
Re:So I switch into Pmode and I call my kernel when
Posted: Tue Aug 29, 2006 5:11 pm
by REV
If I enabled paging will that fix it? Paging is setting the last bit in the CR0 register right?
Well I know for a fact my C/C++ works
I know I was running the Bochs Debugger. Stepping through my bootloader it runs off in a weird direction but some how it later comes back on track with protected mode and then my kernel is called
Re:So I switch into Pmode and I call my kernel when
Posted: Wed Aug 30, 2006 3:22 am
by Combuster
REV wrote:
If I enabled paging will that fix it? Paging is setting the last bit in the CR0 register right?
Paging doesn't fix anything, it only gives you new options. An yes, PG is bit 31 in CR0
Well I know for a fact my C/C++ works
"I heard that one before"
I know I was running the Bochs Debugger. Stepping through my bootloader it runs off in a weird direction but some how it later comes back on track with protected mode and then my kernel is called
In case you wonder, it helps setting breakpoints after INT instructions. You probably ended up debugging the BIOS which is not really where your issues are right now.
Still i didnt hear of anything happening after protected mode was entered. Have you found yet if you got to something like your mov, inc, mov, inc, jmp printing sequence - maybe you can get a disassembly of that with a cpu dump so we can determine wether You or Bochs should upgrade...