OSDev.org

Posted: **Wed Jun 15, 2005 10:34 pm**

ok so i am implemented v8086 mode with the goal of issues a bios interrupt to set my video mode.

I have setup v8086 threads which appear to work just fine (following tim's tutorual i can see the 16-bit code running and filling the registers as i expect and priviledged instructions cause a GPF which is also expected)

So i am trying to setup the handler for priviledge instructions to put the final touches on it....but it isn't working very well

So right now here's my issue. The iret returning from the GPF seems to not be happy.

here's some bochs output of the offending iret

Code: Select all

00243848161i[CPU0 ] -----------------------------------
00243848161i[CPU0 ] selector->index*8 + 7 = 28679
00243848161i[CPU0 ] gdtr.limit = 2047
00243848161i[CPU0 ] fetch_raw_descriptor: GDT: index > limit
00243848161i[CPU0 ] | EAX=00000013  EBX=bbbbbbbb  ECX=cccccccc  EDX=dddddddd
00243848161i[CPU0 ] | ESP=e0011030  EBP=33333333  ESI=22222222  EDI=11111111
00243848161i[CPU0 ] | IOPL=0 NV UP EI NG NZ AC PE NC
00243848161i[CPU0 ] | SEG selector     base    limit G D
00243848161i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00243848161i[CPU0 ] |  DS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] |  ES:0000( 0000| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] |  FS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] |  GS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
00243848161i[CPU0 ] | EIP=c0100192 (c0100191)
00243848161i[CPU0 ] | CR0=0xe0000011 CR1=0x00000000 CR2=0x00000000
00243848161i[CPU0 ] | CR3=0x01fdd000 CR4=0x00000000
00243848161i[CPU0 ] >> cf
00243848161i[CPU0 ] >> : iret
00243848161i[CPU0 ] -----------------------------------

I have NO idea where the "selector->index*8 + 7 = 28679" is coming from so that's my first question. (also with some tickering i have gotten an erro about some AR byte which i have no clue what that is either...)

anyway. if i stop just before the iret here's my stack layout (which looks ok to me)

Code: Select all

0xe0011030: 0x00000000 (this is the pushed errcode)
0xe0011034: 0x00007003 (this is the IP i want to end up at)
0xe0011038: 0x00000000 (this is the CS i want to end up at)
0xe001103c: 0x00030202 (these are the eflags for after the iret)
0xe0011040: 0x00008000 (this is the SP i want to end up with)
0xe0011044: 0x00000000 (this is the SS i want to end up with)
0xe0011048: 0x00000040 (this is my expected ES)
0xe001104c: 0x00000041 (this is my expected DS)
0xe0011050: 0x00000042 (this is my expected FS)
0xe0011054: 0x00000043 (this is my expected GS)

which as far as i can tell looks reasonable to return me to my V86 task....

The odd thing is that if my exception handler does NO work at all, i still get this error (which i would expect it to resume and then re-issue the exception in an infinite loop...)

anyone have a clue?

proxy

Posted: **Wed Jun 15, 2005 10:39 pm**

BTW my excpetion handler basically looks like this:

Code: Select all

   .globl   _exception_0D;
_exception_0D:
   pushl $0x0D;
   jmp _exception_call_and_cleanup;

_exception_call_and_cleanup:

   pushl   %ss
   pushl   %ds
   pushl   %es
   pushl   %fs
   pushl   %gs
   pushal
   
   /* change to all kernel mode selectors */
   mov      $0x10, %bx
   mov      %ebx, %ds
   mov      %ebx, %es
   mov      %ebx, %fs
   mov      %ebx, %gs
   
   call exception_handler
   
   popal
   popl   %gs
   popl   %fs
   popl   %es
   popl   %ds
   popl   %ss
   
   /* compensate for exception number pushed earlier */
   add $4, %esp   
   iret

and my general exception trap code is this:

Code: Select all

extern "C" void exception_handler(struct context_t context) {

   switch(context.int_number) {
   case 0x00: Exceptions::cpu00(&context); break;
   case 0x01: Exceptions::cpu01(&context); break;
   case 0x02: Exceptions::cpu02(&context); break;
   case 0x03: Exceptions::cpu03(&context); break;
   case 0x04: Exceptions::cpu04(&context); break;
   case 0x05: Exceptions::cpu05(&context); break;
   case 0x06: Exceptions::cpu06(&context); break;
   case 0x07: Exceptions::cpu07(&context); break;
   case 0x08: Exceptions::cpu08(&context); break;
   case 0x09: Exceptions::cpu09(&context); break;
   case 0x0a: Exceptions::cpu0a(&context); break;
   case 0x0b: Exceptions::cpu0b(&context); break;
   case 0x0c: Exceptions::cpu0c(&context); break;
   case 0x0d: Exceptions::cpu0d(&context); break;
   case 0x0e: Exceptions::cpu0e(&context); break;
   case 0x0f: Exceptions::cpu0f(&context); break;
   case 0x10: Exceptions::cpu10(&context); break;
   default:
      Exceptions::cpu0f(&context); break;
   }   
}

Posted: **Wed Jun 15, 2005 11:05 pm**

Are you POP'ing (or "addl $4, %esp" or whatever) the errorcode?

Posted: **Wed Jun 15, 2005 11:33 pm**

no because it was pushed by the exception itself so it is supposed to be on the stack.

proxy

Posted: **Wed Jun 15, 2005 11:40 pm**

You are supposed to get rid of the errorcode before IRET.

Posted: **Wed Jun 15, 2005 11:43 pm**

oh snap! hehe, that does fix it (well i still need to finish my v86 monitor).

sweet thanks, i never noticed that in any documentation.

proxy

Posted: **Thu Jun 16, 2005 12:27 am**

Something else, why are you pushing and popping SS? SS is already set to the kernel stack segment, you're pushing it, popping it then popping it again using the IRET.

Posted: **Thu Jun 16, 2005 8:42 am**

good question, i;m on the fense of how useful it is...i originally did it so my exception handler can report what the the current SS is simply by looking at my cointext structure...but now that i think of it, it will ALWAYS be the kernel mode SS at this point...so i'll probably chop that

proxy

OSDev.org

having an issue with v8086 mode

having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode

Re:having an issue with v8086 mode