OSDev.org

Here and I thought I was getting proficient at assembly :'(

Anyway, I thought I knew how to use pointers, so I developed this code, just to move the value 2 into the address 0x9c000:



It compiles without any errors, but then I use bochs to check the value of 0x9c000 and there's nothing there. To give a little context: this is in my kernel's assembly stub, right after the bootloader. There's no GDT magic going on or anything. There is no reason that I can think of that would make 0x9c000 equal anything but itself.

Any ideas?

is executed as



If DS' base (in pmode) or DS' value (in realmode) is not zero, then the address you're generating is above what you expected.
Check your DS value and report if it's zero.

I don't think that's the problem, considering DS = 0x10 which is legitimately the DATASEL in my GDT and (as I said) there isn't any funny GDT stuff going on (i.e. the bases are zero).

That is the correct instruction for writing at that memory location, if your segments are flat and paging is off then it should work fine. If it doesn't then it is either A) Not being executed at all or B) Being executed but then being deleted by something else before you test it [or C) You aren't testing it properly].

A) It's being executed... as far as I can tell. It's right before the jmp $ loop that I've got set up and that's certainly being executed. Since it's the first instruction in the kernel, the processor jumps right to it, in fact.

B) Nothing else is running. The bootloader has just popped the kernel in at 1MB, we've just jumped there... we literally write the 2 and then halt the entire operating system.

C) The most probable answer, but how else would you test this than just "x 0x9c000" in the bochs debugger? This, of course, returns 0x00000000.

could you be missing a "bits 32" directive or something alike ?

Nope, the kstart.asm file starts with [BITS 32]...

One thing that may be related, though I doubt it, is that I'm running on a 64bit Linux machine. The only reason I say that that's probably unrelated though is that fact that I'm pretty sure that the linker isn't the problem and that nasm is generating OK code (considering the bootloader's written in it too and it's not broken and if I take the jmp $ line out it boots properly...). GCC shouldn't be an issue either, considering there hasn't been a lick of C code executed at the time of this failure.

This does remind me of another problem that I had with my kernel.c osmain() function... if I ever put a while(1) loop too close to the beginning of it, the linker either hangs or outputs a ridiculously huge kernel (>128k). Again, this seems unrelated, but since it seems like we're all just grasping at straws, I figure what the hell.

I don't think I ever got anything else then zero with that.. hrrmm.. crappy debugger. *apologies to pype*

Well, I've gotta say that I've used Bochs to debug everything in my OS to good ends. Without it paging would've been a complete and utter kludge. I trust bochs.

maybe you may like to set up a breakpoint on the first kernel instruction (e.g. pbreak 0x100000) to make sure the instruction is actually executed ...

do you have a diskimage of it ?

Here's the funny thing: I just found out that my edition of Bochs seg faults when I try and pbreak anything =) Hooray. ;D

Anyway, I do happen to have a diskimage (here: www.codezen.org/viridis/image.img)... that's the entire OS, bootloader and kernel, ready to be written (or booted in Bochs, as is the case here).

Recompiled Bochs, it works now, this is the output:



So it executes... still no go.

So it seems you're not exactly using 0-based segments ... "x" does show a linear address and "xp" a physical address, but none do show a 'ds:offset', so you'll have to compensate yourself.

trouble is with ds.base == 0x40100000, offset "0x9c000" is way out of the valid addresses (on my simulator atleast). Keep in mind that the linker does *not* see constant addresses thus you need to patch them yourself in your ASM code (or use ORG 0x40100000)

[me=wangpeng]tears own hair out[/me]

... I'm f'ing retarded. I recently unarchived a backup from awhile ago and forgot that I still needed to change the DATASEL back to flat base addressing (like I had with the CODESEL).

What a waste of time. Thanks for your time.