OSDev.org

I see a page in FAQ called [wiki]http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working[/wiki]. However, I see many forum posts saying that loading the GDT causes a triple fault. I created one of these forum posts a few days ago, and I got good answers with simple fixes. So, why don't we create a "Help! I can't get a GDT working"?

It's a wiki, anyone can create any page. If there's a page that you think should exist, then create it.

I wonder whether it's really necessary to have a page on the GDT, another on the instruction that loads it, a tutorial on how to set it, a whole bunch of other pages describing x86 segmentation and related things, and now a dedicated FAQ. It's just a simple record whose fields describe segments. I think the problem is not missing information but very poor computer science education on elementary topics.

Love4Boobies wrote:I wonder whether it's really necessary to have a page on the GDT, another on the instruction that loads it, a tutorial on how to set it, a whole bunch of other pages describing x86 segmentation and related things, and now a dedicated FAQ. It's just a simple record whose fields describe segments. I think the problem is not missing information but very poor computer science education on elementary topics.

I think it has more to do with the ability to work with information than with basics of CS per se.
It's about dealing with unknown unknown, filling the gaps, which is aggravated by several factors: too much info, not easy to digest due to the way written, not just the sheer amount, and, finally, in the particular case of system things like GDT, IDT and page translation the ease of screwing up. It either works or, most often, during the first several attempts, it does not and the code crashes spectacularly and there's little clue available immediately as to why.

Perhaps I'm wrong about this but I remain unconvinced that it has to do with any of the things you've mentioned because people are usually quite comfortable dealing with huge amounts of incomplete information in their regular lives. The one exception to this is the dry way in which technical documentation is written but, on the other hand, it seems a lot simpler to interpret a text whose meaning is literal than to extract meaning from a great novel. It seems to me that the only time people get truly lost is when they are on unfamiliar territory.

Hi,

beauhefley wrote:I see a page in FAQ called [wiki]http://wiki.osdev.org/I_Can%27t_Get_Interrupts_Working[/wiki]. However, I see many forum posts saying that loading the GDT causes a triple fault. I created one of these forum posts a few days ago, and I got good answers with simple fixes. So, why don't we create a "Help! I can't get a GDT working"?

Because everyone has different bugs you'd need a tree of many questions. Something like:

Is loading the GDT supposed to cause a general protection fault (for security reasons - e.g. because the code is running at CPL=3):

• Yes: Congratulations, your kernel is secure!
  No: Is the "GDT pointer" accessible (e.g. with normal read, like "mov eax,[GDTpointer]" instead of "lgdt [GDTpointer]")?
  • No: There's probably a problem with the segment (e.g. DS) that you had before attempting to load a GDT, or some other issue (e.g. page fault, where page fault handler can't start and triggers a general protection fault).
    Yes: Is the GDT limit correct?
    • No:.....

What you really want is an expert system; where it'll start by asking the previously stored questions, and if the previously stored questions don't lead to a solution it'll allow the questions and answers to be extended/improved if/when a solution is found elsewhere.


Cheers,

Brendan

I think what most people want is to have the code handed to them. If they don't have the time to study the documentation, they certainly don't have time to go through every possible scenario.

Love4Boobies wrote:Perhaps I'm wrong about this but I remain unconvinced that it has to do with any of the things you've mentioned because people are usually quite comfortable dealing with huge amounts of incomplete information in their regular lives.

In our "regular lives" we don't have to be exactly precise in like a hundred of subsequent actions. Our movements are approximate, but we still make it from point A to point B. Our judgement (including risk assessment) is often quite sloppy too, but we can still live and multiply all the while doing silly things and believing strange things. Wrong change at the store? Thinking a person is (being) mean if they don't smile at you or chitchat with you? Imprecision and mistakes here usually don't cause grave immediate problems. And often times you can interact with other people to get issues resolved. Here, OTOH, you can't plead, incentivize or threaten the CPU to run your code to your satisfaction. You need to talk to it by the book. With precision. Step by step for hundreds of steps. And the book is big and boring. And it has a number of mistakes and ambiguities here and there and you have to make sense of it. Every little thing you ignore because you think you know it or you think it's unimportant, while in reality it's the other way around, every little thing like that may be the very reason why the CPU is "acting up".

Love4Boobies wrote:The one exception to this is the dry way in which technical documentation is written but, on the other hand, it seems a lot simpler to interpret a text whose meaning is literal than to extract meaning from a great novel. It seems to me that the only time people get truly lost is when they are on unfamiliar territory.

But maybe you're right. Maybe both of us are right. If you make the circle noting that people turn to other people with their programming problems and eventually figure stuff out, become comfortable and skilled...

On topic, my experience is that the majority of GDT problems are caused by having the wrong data in the table itself. Not understanding how the base addresses and lengths are stored, not understanding what the various bit flags mean or where they're stored, and so on. Usually an endianess or bit-ordering problem, sometimes a lack of understanding of what all the terminology means. These problems become especially noticeable when one is trying to use something other than a flat memory model (or with a flat or semi-flat memory model, in a year's time when they eventually exceed the incorrectly-set limit of their kernel code segment or whatever).