Something that cannot be described in a subject li - 2006/08/29 20:22 I'm one of those guys who built their OS as a "prototype" in another Operating system by not using any libraries.
I did that so most of my code was already built and I didn't waste away builds with testing stuff.
Well I finally got my code to switch over to protected mode and run the C/C++ code. Well nothing is getting printed. So I just compiled a real easy kernel with just some basic stuff:
Alright so a gray ! should be printed. Insteading nothing. And when main() is finished my second stage code just halts.
The people on the megatokyo board said the memory may not be mapped. Whats going on?
| | The administrator has disabled public write access.
OSDEV Community
Advertisement
gaf
User Platinum Osdever
Posts: 153
Karma: 10
Re:Something that cannot be described in a subject li - 2006/08/30 10:14(Click here to open the mega-tokyo thread about this topic)
The people on the megatokyo board said the memory may not be mapped. Whats going on? Candy probably thought that you might be using paging. As long as you don't set the PG bit in cr0 paging is however disabled and you won't have to map anything.
Well I finally got my code to switch over to protected mode and run the C/C++ code. Well nothing is getting printed. So I just compiled a real easy kernel with just some basic stuff: There seems to be some problem during the linking process. From what I can tell the global variable text-address has not been relocated to your kernel's base address:
Code:
0: fa cli
1: e8 02 00 00 00 call 0x8
6: fa cli
7: f4 hlt
8: 68 08 00 00 00 push $0x8
d: e8 ed ff fe ff call 0xfffeffff // stack ?
12: 52 push %edx
13: a1 37 00 00 00 mov 0x37,%eax // load text-address
18: 8d 50 01 lea 0x1(%eax),%edx // increase by one
1b: 89 15 37 00 00 00 mov %edx,0x37 // store value
21: c6 00 21 movb $0x21,(%eax) // write !
24: a1 37 00 00 00 mov 0x37,%eax // load text-address
29: 8d 50 01 lea 0x1(%eax),%edx // increase by one
2c: 89 15 37 00 00 00 mov %edx,0x37 // store value
32: c6 00 07 movb $0x7,(%eax) // write attribute
35: eb fe jmp 0x35 // hang
37: 00 80 0b 00 .dword 0x000B8000 // text-address data
As your kernel gets loaded to 0x10000 the address of your text-address variable should acctually be 0x10037 and not just 0x37. You'll have to tell Watcom/JLOC to link the binary to your base by either using some linker-script or by passing another parameter to the compiler.
You can use the above code to find out if the relocation address is really your problem. It uses a local variable to access video-memory and should thus work regardless of your base address.
Assigning a selector (0x10) to ES FS and GS would probably be a good idea. It's not the cause of your current problem, but you will eventually run into trouble as the C++ compiler must access these segments.
regards,
gaf
| | The administrator has disabled public write access.
Mike359
User Senior Osdever
Posts: 27
Karma: 1
Re:Something that cannot be described in a subject - 2006/08/30 13:22Yeah it printed the text alright. Argggh how can I command JLOC (or Watcom) to relocate the varibles?
| | The administrator has disabled public write access.
gaf
User Platinum Osdever
Posts: 153
Karma: 10
Re:Something that cannot be described in a subject - 2006/08/30 14:46Hmm, from what I could find out you probably should set the base field to zero rather than 0x10000: According to the documentation it actually seems to be the descriptor/segment base and not you kernel's base.
Code:
section: base start i_start selector
base: base-address of your descriptor (flat-mode: 0)
start: offset in that descriptor (flat-mode: kernel base)
i_start: segment offset in the file
selector: probably only needed for 16bit code ?
Keep in mind that I'm actually more of an ld user: I won't guarantee for anything .
regards,
gaf
| | The administrator has disabled public write access.
Mike359
User Senior Osdever
Posts: 27
Karma: 1
Re:Something that cannot be described in a subject - 2006/08/30 15:30BRAWR! It dosn't workbut i'll figure it out sooner or later. I was going to use LD but it dosn't support the OBJS im using.
| | The administrator has disabled public write access.
gaf
User Platinum Osdever
Posts: 153
Karma: 10
Re:Something that cannot be described in a subject - 2006/08/30 16:35[quot]It doesn't work but i'll figure it out sooner or later. The funny thing is that the JLOC documentation actually even includes a linker-script for a boot-sector:
Code:
ALL:
bootstrap.obj
BOOT: 0 7C00 0
*
According to the docs this "tells JLOC that the assumed segment register points to 0, (and that) the section is actually loaded at 7C00 in memory". That's pretty much the same as you need for your kernel. All you have to do is making sure that the assembler stub gets linked first and that the kernel-base gets set to 0x10000:
Maybe you could also post the hex-code of your updated C kernel ? As the new script will hopefully relocate the kernel as intended, it would probably be a good idea to make sure that there aren't any other problems.
regards,
gaf
| | The administrator has disabled public write access.
Mike359
User Senior Osdever
Posts: 27
Karma: 1
Re:Something that cannot be described in a subject - 2006/08/30 17:26What about the rest of my code and linker script?
| | The administrator has disabled public write access.
Mike359
User Senior Osdever
Posts: 27
Karma: 1
Re:Something that cannot be described in a subject - 2006/08/30 17:57That script didn't map all the segments. Heres the hex dump. Sorry im in a rush
| | The administrator has disabled public write access.
gaf
User Platinum Osdever
Posts: 153
Karma: 10
Re:Something that cannot be described in a subject - 2006/09/01 11:20What about the rest of my code and linker script? As long as you're in 32bit pmode the rest of the code actually shouldnt make a difference.
Code:
startup (assembler):
00: fa cli
01: e8 c7 00 00 00 call 0xcd
06: fa cli
07: f4 hlt
kernel::main()
cd: 53 push %ebx
ce: 51 push %ecx
cf: 52 push %edx
d0: 56 push %esi
d1: 57 push %edi
d2: f4 hlt
d3: e8 eb ff fe ff call 0xffff00c3
d8: e8 ea 00 ff ff call 0xffff01c7
dd: e8 26 ff fe ff call 0xffff0008
e2: e8 70 ff fe ff call 0xffff0057
e7: e8 89 ff fe ff call 0xffff0075
ec: e8 85 ff fe ff call 0xffff0076
f1: 5f pop %edi
f2: 5e pop %esi
f3: 5a pop %edx
f4: 59 pop %ecx
f5: 5b pop %ebx
f6: c3 ret
What really surpised me is that the main() calls in your assembler start-up code works perfectly fine, while all calls in the kernel itself are still broken. On the other hand jumps seem to work in all source-files .
Let's have a look at the call at address 0xd3 in the hex dump (e8 eb ff fe ff). The first byte is the opcode of the relative call, while the other 4 bytes define the value to be added to EIP (0xfffeff). As it's an ordinary signed 32bit number, we can get the absolute value by doing a two's complement:
0xfffeffeb -invert-> 0x10014 -add-> 0x10013
The resulting value (-0x10013) gets now added to the address following the call instruction (0x100d8), so that we eventually end up with 0xc5 and not 0x100C5 as intended.
In my opinion this behaviour is really weird: The linker now seems to have understood that it's currently at a location greater than 0x10000 - otherwise the calls wouldn't be broken. On the other hand it however doesn't seem to know that all the other procedures, aswell as the data-section, are also located at 0x10000+ - thus global variables still don't get accessed correctly.
It's definitly a problem with the linker, and I'm afraid that I know too little about JLOC to be much of a help here. Maybe it would be a good idea to reactivate your mega-tokyo thread: If you're lucky there should be some other JLOC user on that board..
regards,
gaf
| | The administrator has disabled public write access.
Mike359
User Senior Osdever
Posts: 27
Karma: 1
Re:Something that cannot be described in a subject - 2006/09/01 12:48Ill post a topic in the old thread. I also have a problem with Watcom. It inserts function calls like that when I call functions which crash the kernel. Gaf do you have MSN? Add me Mike359@Gmail.Com
Post edited by: Mike359, at: 2006/09/01 12:58
| | The administrator has disabled public write access.
Forums 
.
.
