OSDev.org

LtG wrote:What is this favorite OS? Btw, I'm sure you've made the distinction of having an OO OS as opposed to creating an OS in an OOP language.

OS/2.

Octacone wrote:

dozniak wrote:Looks like one of your ctors simply overwrites Multiboot_Info memory.

Is that my fault anyhow?

Definitely, these are your constructors after all.

LtG wrote:

Octacone wrote:

dozniak wrote:Looks like one of your ctors simply overwrites Multiboot_Info memory.

Is that my fault anyhow?

Are we supposed to know/guess what _all_ of your constructors do?

Btw, do you make any allocations (new/malloc) in any of your constructors?

I actually did that once, but I quickly realized it was not going to work.

dozniak wrote:

Octacone wrote:

dozniak wrote:Looks like one of your ctors simply overwrites Multiboot_Info memory.

Is that my fault anyhow?

Definitely, these are your constructors after all.

So I can't blame the compiler, such a shame.

I might actually remove them after all. Not pulling any extreme usage out of them, we'll see.

In my opinion C++ is very capable language. C is kind of rusty and old, unable to perform the same abstractions as C++.

Edit: I removed my previous post, it is not fixed.
Actually GRUB memory issue was fixed, but the main issue is still there.
Now -O2 and no -O2 have switched their places.
-O2 = triple fault
-No -O2 = everything is okay

When I disabled the interrupts/paging it doesn't crash.

C++ is, indeed, a very capable language. But using it doesn't automatically make a person a very capable programmer.

iansjack wrote:C++ is, indeed, a very capable language. But using it doesn't automatically make a person a very capable programmer.

Couldn't agree more.

It looks like all the battles have been lost. Since I cannot debug anymore, GDB doesn't work with optimizations enabled.
The only way I can stop this "bug" from happening is to disable paging or interrupts.

So >> No shell array, kernel works just fine, everything is okay, paging works. But still page_directory->physical_page_tables returns 0x0. Why does compile put that at 0x0.

@LtG about what you asked earlier:
virtual page tables* ----> pages and their flags //allocations needed
physical page tables ----> address of above page tables and their flags //allocation not needed, compiler placed

Octacone wrote:Edit: I removed my previous post, it is not fixed.
Actually GRUB memory issue was fixed, but the main issue is still there.
Now -O2 and no -O2 have switched their places.
-O2 = triple fault
-No -O2 = everything is okay

When I disabled the interrupts/paging it doesn't crash.

Is your interrupt handler corrupting your memory?

Is your paging set up incorrectly and causes some other code to corrupt your memory?

Investigate:
- your binary layout upon start
- location and contents of MB info _before_ you run any constructors
- contents of kernel layout after you set up paging
- location and contents of MB info _after_ you set up paging
- are any interrupt handlers run before, during or after you set up paging
- location and contents of MB info _after_ interrupt handlers run, if any

Ideally dump the entire MB info and compare to what it should be.

There is definitely some paranormal activity going on inside my kernel. I found out some randomly mapped pages out of nowhere. Also I am stripping it piece by piece to figure out the source of this specific problem.
@dozniak I already fixed that issue.

Octacone wrote:It looks like all the battles have been lost. Since I cannot debug anymore, GDB doesn't work with optimizations enabled.
The only way I can stop this "bug" from happening is to disable paging or interrupts.

So >> No shell array, kernel works just fine, everything is okay, paging works. But still page_directory->physical_page_tables returns 0x0. Why does compile put that at 0x0.

@LtG about what you asked earlier:
virtual page tables* ----> pages and their flags //allocations needed
physical page tables ----> address of above page tables and their flags //allocation not needed, compiler placed

The longer this thread goes on the clearer it becomes that you don't seem to have the basic fundamental understanding required:
- C/C++
- Pointers in languages like C/C++
- Paging

You seem to be under the illusion that once you find and fix the next bug it's going to work, when in fact you should actually learn the basic concepts and then either start from scratch or go thru all of your code and fixing all of it.

Not sure if it's just me, but I've actually thought that you're a troll based on your replies in this thread... Not really any specific reply but rather the whole thread itself..

LtG wrote:

Octacone wrote:It looks like all the battles have been lost. Since I cannot debug anymore, GDB doesn't work with optimizations enabled.
The only way I can stop this "bug" from happening is to disable paging or interrupts.

So >> No shell array, kernel works just fine, everything is okay, paging works. But still page_directory->physical_page_tables returns 0x0. Why does compile put that at 0x0.

@LtG about what you asked earlier:
virtual page tables* ----> pages and their flags //allocations needed
physical page tables ----> address of above page tables and their flags //allocation not needed, compiler placed

The longer this thread goes on the clearer it becomes that you don't seem to have the basic fundamental understanding required:
- C/C++
- Pointers in languages like C/C++
- Paging

You seem to be under the illusion that once you find and fix the next bug it's going to work, when in fact you should actually learn the basic concepts and then either start from scratch or go thru all of your code and fixing all of it.

Not sure if it's just me, but I've actually thought that you're a troll based on your replies in this thread... Not really any specific reply but rather the whole thread itself..

That is very very very wrong. I do have everything needed to work on a project like this. I do have a basic (more than that obviously) understanding of C/C++ and pointers. I've been programming in .NET languages for years working on small and casual projects.

A simple bug is not going to stop me for working on my dream project. Right now I am going trough all of my code fixing everything I can see, also the bug has gone away.
Why would you think I'd be trolling? That is such nonsense.
It might seem at first like I have no clue what is going on, I don't quite have a clue when it comes to this specific case, but generally speaking I do indeed.
My debugging skill are not as good as yours but I am trying, this is actually the first time I've used GDB, ever.
This whole this is just a big learning exercise for me. I am not going to quit because there is a line of code that crashes my kernel. My goal is to find it, fix it and try to understand why did it happen.
Now excuse me I have to continue fixing my nonsense code and try to learn something while trying. I am not a trained professional, just a hobbyist. Don't expect me to be all mighty and know every single detail of everything.
It seems like you don't understand how paging works either, because you are questioning my design choices without even ever taking a look at it fully.
Sorry if this thread looks "dumb" to you, but that is how trial and error looks like.

Since I fixed the bug by properly allocating strings (bunch of them actually) I mark this topic closed. @LtG if you have any further question feel free to PM me.

Octacone wrote: A simple bug is not going to stop me for working on my dream project. Right now I am going trough all of my code fixing everything I can see, also the bug has gone away.

Good, it shouldn't.

Octacone wrote: Why would you think I'd be trolling? That is such nonsense.
It might seem at first like I have no clue what is going on, I don't quite have a clue when it comes to this specific case, but generally speaking I do indeed.

As I said, based on the replies in _this_ thread. It might as well be because of lack of experience. Trolls often employ techniques such as:
- Vague responses
- Omitting key details
- Not answering all questions
- etc

You've done all three in this thread, and trolls use all three to ensure things don't progress forward, or at best do so slowly. For instance if you post a picture of two side by side dis-asm's, it would be useful to actually say what those are and which is which, without somebody having to ask. Of course simple mistakes happen..

I think at least a few times you didn't answer some questions, though in one case at least you responded to it significantly later, which also helps to create confusion.

I'm not saying you are a troll, just that this thread started to appear as such.

Octacone wrote: My debugging skill are not as good as yours but I am trying, this is actually the first time I've used GDB, ever.

Unless you do extreme unit testing, a debugger (gdb or something else) is your best friend. Even if you ignore all the fancy stuff, the very basic feature of being able to check register contents and single-stepping is all you really need, and that doesn't require gdb knowledge. Of course you will very quickly get tired of single-stepping which is where break points come in, but still no gdb knowledge required.

I'm no master at _gdb_, but debugging isn't really tied to a specific debugger. You just need to follow the flow of code to understand why something is happening and then work backwards. Also having gdb print the C code along with the dis-asm while single stepping does help, even if you don't fully understand all asm.

Octacone wrote: It seems like you don't understand how paging works either, because you are questioning my design choices without even ever taking a look at it fully.

None of us have seen all of your code, so are you suggesting none of us should have responded?

I was commenting based on what I have seen and what I can extrapolate from that. I'm guessing that you are likely doing something overly complicated with no good benefit. If you look at the example code in the paging part of the Wiki you should see that paging is actually very simple. It's usually different types of optimizations that may make it more complex, but you shouldn't attempt _any_ optimizations to paging until you actually have it working.

Octacone wrote: Sorry if this thread looks "dumb" to you, but that is how trial and error looks like.

Trial and error is not a good way to solve anything, especially when done in this manner. From my perspective it seemed like you wanted to try _anything_ that might work, and you shouldn't. You should try to understand the problem and then fix it. Often we think trying random things is easier/faster, but in reality it's often (almost always) more beneficial to stop, learn, then fix. But we tend to think the learning will take too long and thus want to skip it.

Note, this is pretty much the problem in politics as well, let's try random stuff then at least we can say: "we did _something_", too bad something random isn't likely to yield the wanted outcome.

Octacone wrote: Since I fixed the bug by properly allocating strings (bunch of them actually) I mark this topic closed. @LtG if you have any further question feel free to PM me.

Probably a good idea to drop this thread, allows the next to start fresh at a specific problem.. As for PM, I usually avoid those as they don't contribute as much to the public knowledge base.. Similar to in some cases people reply to their own threads: "I solved it!", which is incredibly annoying two years later for the next guy who now believes a solution exists but doesn't get to know what it is =)

LtG wrote:

Octacone wrote: Since I fixed the bug by properly allocating strings (bunch of them actually) I mark this topic closed. @LtG if you have any further question feel free to PM me.

Probably a good idea to drop this thread, allows the next to start fresh at a specific problem....Similar to in some cases people reply to their own threads: "I solved it!", which is incredibly annoying two years later for the next guy who now believes a solution exists but doesn't get to know what it is =)

In my experience, people who post "I solved it" rarely have done so. At least not the real problem. Making a bug, apparently, go away without understanding why is not a solution. It's another problem waiting to rear its ugly head.

@LtG @iansjack
I actually don't respond when I don't know what to respond. Sometimes some replies are very long so I unintentionally skip them. Quoting them is ever worse.
Also some updates if you want to know. I found out what those "paranormal" mapping activities were. I was passing every single one of those 1024 virtual page tables to the page directory. Which means random mappings caused by some random garbage.
Then I found out an entire chunk of overlapping mappings, aka mapping the same thing twice. My paging mechanism is actually quite compact, around 130 lines of code.
I am in fact responding to everything you guys commented, just not directly line by line, but more contextually (trough this entire post, "bunched up together" in a way).
Currently I am reviewing my entire code and trying to see if there are any obvious mistakes and bad decision choices.
About the thing you said, not posting enough info and such: I don't have it either. (Bochs refuses to speak, Qemu is more or less useless, GDB doesn't work with -O2)
Excuse me if I missed anything. I am having to go back and forth and reading everything again because I keep forgetting what you said.
Side note: if anyone is interested in seeing my paging code, I can show it to them privately (inbox). Don't want to share something people are just going to copy and paste without understanding anything.

I see no reason why GDB shouldn't be able to work even with -O2. It may behave strangely, like jump across lines, or not display variables, but it should at least allow you to trace instructions with si and ni, as well as set breakpoints at the function entry points. Also, try to set access point somewhere in your page tables prior to their initialization (; assuming access points work).

Edit: I meant access breakpoint; It is called watchpoint in gdb (the "watch" command)