OSDev.org

How do i set up a stack segment selector descriptor i tried this but keep getting an error. what is wrong
STACK_SEL   equ   $-gdt_start
   dw   0x0000    ; Limit(1):0x0000
   dw   0xffff    ; Base(3)
   db   0x0e    ; Base(2)
   db   0x96    ; Type // 0x92 also gives error
   db   0x41    ; Limit(1):0x4 | Flags:1byte inc,32bit (01000001)
   db   0x00    ; Base(1)

when i move this to SS and then 0xffff to SP i get an error in BOCHS. How do i set up a 64k stack descriptor

if you really want a 64K segment, it would make more sense to set your limit to 0xffff and leave the "granularity" bit to 0. setting the limit to 0x10000 actually declare a 65537-bytes segments (odd, no ?)
Setting esp to 0xffff will *not* be a good idea on such a segment, for it is not aligned and it could ask for bytes that are out of the segment (if you try to access the dword at ss:esp, the two first byte are in your 65537 bytes segment, but not the highest two bytes. A limit of 0xfffc is a better idea.

what about this one is this selector efficient to use SP=0xffff
      dw   0xffff    ; Limit(2):0xffff
      dw   0x0000 ; Base(3):0x1f0000
      db   0x1f    ; Base(2)
      db   0x92    ; Type: prsent,ring0,data/stack,read/write (1001 0010)
      db   0x40    ; Limit(1) Flags:1byte inc,32bit (01000001)
      db   0x00    ; Base(1)

it does not seem more efficient. For an efficient selector, make sure (gdt[ss].base+esp)%4==0.

Note that if you use a separate segment for your stack, you won't be able to write code for your OS in C (or probably any other high-level language).

Most C compilers assume that memory accessed through the stack (local variables and function parameters) is the same as memory access anywhere else -- which won't be the case if you give your stack segment a different base address from your data segment.

Tim Robinson wrote: Note that if you use a separate segment for your stack, you won't be able to write code for your OS in C (or probably any other high-level language).

No, Tim. This is a common mistake. You *can* have one segment per stack provided that all the stacks have the same base (which is also the base of the data segment, but does not necessarily coincide with the base of the code segment), which leaves you free to use the limit as you want (for instance to implement segment-based stack overflows).

You may argue that a stack overflow can be caught with a page fault instead, but this is hard to achieve for kernel-level stack (where will you push the return address if the stack overflowed ? You're likely to get a tripple fault) while you can easily set the "stack fault" descriptor as a Task Gate (if the kernel stack overflows, a "recovery" task will be called and will try to resume the situation or panic gracefully).

I use this technique in Clicker, and it works quite well. It means that i can keep fast interrupts for 'traditionnal page faults' and a robust handling of kernel panics.

Pype.Clicker wrote:You *can* have one segment per stack provided that all the stacks have the same base (which is also the base of the data segment, but does not necessarily coincide with the base of the code segment), which leaves you free to use the limit as you want (for instance to implement segment-based stack overflows).

Sorry, I should made that clear in my post ("...which won't be the case if you give your stack segment a different base address from your data segment").