Do I need segmentation?

[Phil]

Hi,

I've just been reading Tim Robinsons Memory Management 1 Tutorial (http://osdev.neopages.net/tutorials/memory1.php). He says that no mainstream compilers can handle segmentation in 32-bit mode.

If they cannot handle it, is there any point in using segmentation?

As an aside, can anyone suggest any good tutorials on GDTs, LDTs, IDTs and the like?

Thanks in advance

[gtsphere]

From the basic knowledge of memory management that i have, mapping the entire memory as a segment and then using paging is a "better" option. The intel processer though cannot turn off segmentation, unlike powerpc's which use only paging. I think the processor would be a lot easier to understand if paging was, so to speak, a default option.

As for how the GDT's, LDT's, etc are set up I would really recommend the Intel manuals
www.intel.com then go to literature section.

hope this helps!
-GT

[Pype.Clicker]

i think there *is* a point using segments, for instance to isolate threads' stacks from each others, restrict properly user code access, etc.

The compiler might not handle far calls, for instance, but this doesn't prevent you -- the system dezigner -- to define some stub code that will present a far call as a local call (through a trampoline function), and give some library code more privileges than what the application actually gets ...

It can also help you running several programs in the same address space (for instance to speed up shells) ...

[Phil]

K, thanks everyone. Guess I'm going to implement segmentation.

Phil

[Tim]

You can't avoid segmentation on the x86 since there is no 'segmentation enable' bit like there is for paging. You can put segmentation to good use if you want, but its usefulness is limited with current compilers and linkers (gcc and ld assume that all segments have the same base address and that data accessed through one segment can be accessed at the same address in another).

[Pype.Clicker]

Tim: With the power of operators overloading, you could design a C++ class that will abstract function classes, which could work with far calls.

[Slasher]

Clicker, could you expand on what you just said. small example will be nice ;D

[Pype.Clicker]

okay, let's say you have a library that does screen rendering, not at kernel level, because you don't trust it enough to let it access your page tables and stuff, but not at the user level because you don't trust applications enough to let them write to the video hardware ...

So you wish your video library to be somewhere at DPL2 or DPL1 ...
But this means you cannot call these function while in C/C++ because the compiler don't know about jmp segment:offset ...

This is where Linking Skillz will help you. When loading the application, you'll reserve the space for a "trampoline table" which is just a list of "MOV EAX,CODE ; CALL CALLGATE:0 ; RET" instructions and make the application believe that DrawWindow function is located in that trampoline table.

Code: Select all

DrawWindow:
    mov eax,__video_draw_window_code
    call __video_callgate:0
    ret

Now you load the video library and you will resolve all the constants in the trampoline table (i.e. you can fill in the codes and call gates values in your generated code).

And voil?. You can call the library safely, with any 32bits compiler...

[Pype.Clicker]

Now, imagine you want one of the library function to return a pointer to one of its function ... what will you do ?
In C, you must have a struct FarPtr and have to call it. Not flexible. You need a special case whether the pointer is near or far, etc.

In C++, you can have

Code: Select all

virtual class Callback {
    virtual operator();
}

Note that i'm no C++ guru, but what i try to have is a framework where callback() can be called (you don't even see you have something else than a function pointer ... otherwise callback.call() would have been required ... not here baby )

Now, you can extend that class with NearCallBack, which just perform a near call, or

Code: Select all

class FarCallback :public Callback {
    inline operator() { 
          unsigned ret;
          asm("lcall %1":"=a"(ret):"0"(code),"m"(&CallGate));
    }
private:
    unsigned code; //!< identifies the command to be called
    FarPtr CallGate; //!< what will you jump to ;-)
}

The same technique can be used to build up Callbacks from the user world to the library (but the calling mechanism will be more complex as we need to go one DPL level down, which hasn't been foreseen by Intel developers).