Jump to content

doubt with sidt instruction

- - - - -

  • Please log in to reply
5 replies to this topic

#1
IlikeProgramming

IlikeProgramming

    Newbie

  • Members
  • PipPip
  • 11 posts
Doubts with sidt instruction.

Hi Friends! I have a doubt with the sidt instruction. The Intel documentation for “SIDT m”
stated:


Stores the content of the IDTR in the destination

 operand. The destination operand specifies a 6-byte memory location.

 

If the operand-size attribute is 32 bits, the 16-bit limit field of

 the register is stored in the low 2 bytes of the memory location and the 32-bit base address is stored in the high 4 bytes.



DEST[0:15] <- IDTR(Limit);


DEST[16:47] <- IDTR(Base); (* Full 32-bit base address stored *)




I don't understand why they talk about operand-size attribute of 32 bits, when they say that the destination specifies a 6-byte (48 bits ) memory location. Can someone explain me this??

I am new with assembly code. Thank you very much!!!

#2
RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,252 posts
  • Location:C:\Countries\US
The operand size is 32-bit, while the structure in memory that the operand points to is 6 bytes in size.

In other words, if you're the processor, and I'm the program, I give you a 4-byte memory address and ask for the current IDT. Then you go to the memory address I gave you and you save the 6-byte IDT data at that address. Then I can go to that address and look at the data you saved there for me.

#3
IlikeProgramming

IlikeProgramming

    Newbie

  • Members
  • PipPip
  • 11 posts
Hi RhetoricalRuvim!! I think I understood you. Therefore, would be this code correct??


.section .data

dir_idt:

.int 1

.section .bss


.section .text

.globl _start



#storing the idt in the dir_idt address

  sidt dir_idt 



#the end of the program

  movl $1, %eax

  movl $0, %ebx

  int $0x80


I am testing this software using gdb in linux. And it fills dir_idt byte, and another 2 bytes.

So maybe the address destination should be double instead of int, isn't it?? Because it fills 6 bytes of data, and it are 4 bytes.....
Thank you very much!!!
Thank you very much!

#4
RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,252 posts
  • Location:C:\Countries\US

IlikeProgramming said:

dir_idt:

.int 1

How about something like this?:
dir_idt: 

.limit: 

dw 0 

.base: 

dd 0 

That way you would have a word (16-bit) value for the limit, followed by a double-word (32-bit) value for the base.

* * *

Also, SIDT is a system instruction; are you sure Linux would let you use the SIDT instruction? Or is GDB a virtual machine?

#5
IlikeProgramming

IlikeProgramming

    Newbie

  • Members
  • PipPip
  • 11 posts
thanks again, but the assembler says this:

no such instruction: `dw 0'

no such instruction: `dd 0'


Maybe that's because I am using the gas assembler, and it doesn't recognize this directives.
But following your advices and mapping to the gas assembler, I get this one who works:

.section .data


.section .bss

dir_idt:

.lcomm limit 2

.lcomm base 4


.section .text

.globl _start


_start:


#storing the idt in the dir_idt address

  sidt dir_idt 



#the end of the program

  movl $1, %eax

  movl $0, %ebx

  int $0x80



And Linux let me use sidt instruction from user mode, because it can be executed at any level privilege.

Thank you very very much RhetoricalRuvim!!!

#6
RhetoricalRuvim

RhetoricalRuvim

    JavaScript Programmer

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,252 posts
  • Location:C:\Countries\US
Yeah, the code I gave you is for NASM; MASM/MASM32 would prefer something more like this:
dir_idt_limit    dw 0 

dir_idt_base       dd 0 

From what I can remember off the top of my head, MASM32 doesn't like *.* labels, and complains whenever the user tries to do that.

So you're basically reserving 2 bytes for the limit and 4 bytes for the base, right? That's basically what DW and DD do.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users