- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
I am using `sgdt' instruction in my user space application and don't really
understand the results. The point is when I run application more time `sgdt'
doesn't return the same result every time. I am talking about returned base address of GDT which is seems to be not same every time I run the instruction. See my code below.
So my question is:
Is the GDTR content constant all the time the linux is running?
Regards,
pocdevel.
#include
typedef struct {
unsigned short limit;
unsigned int base __attribute__((packed));
} gdt_t;
static inline gdt_t* inl_sgdt(gdt_t* m)
{
__asm__ __volatile__("sgdt %0":"=m"(*m)::"memory");
return m;
}
int main(void)
{
gdt_t gdt;
printf("--- Checking `inl_sgdt' --- ");
inl_sgdt((gdt_t*)&gdt);
printf("base: 0x%X limit: 0x%X sizeof: %d ", gdt.base, gdt.limit, sizeof(gdt));
return 0;
}
Now if you run the code more times you should get different values for base address (gdt.base). I my case are:
base: 0xC1813000 limit: 0xFF sizeof: 6
...
base: 0xC1809000 limit: 0xFF sizeof: 6
If I understand well `sgdt' instruction should store 6 bytes content of GDTR at given address (in my case &gdt). I don't understand why I get two different
values for gdt.base.
I am using `sgdt' instruction in my user space application and don't really
understand the results. The point is when I run application more time `sgdt'
doesn't return the same result every time. I am talking about returned base address of GDT which is seems to be not same every time I run the instruction. See my code below.
So my question is:
Is the GDTR content constant all the time the linux is running?
Regards,
pocdevel.
#include
typedef struct {
unsigned short limit;
unsigned int base __attribute__((packed));
} gdt_t;
static inline gdt_t* inl_sgdt(gdt_t* m)
{
__asm__ __volatile__("sgdt %0":"=m"(*m)::"memory");
return m;
}
int main(void)
{
gdt_t gdt;
printf("--- Checking `inl_sgdt' --- ");
inl_sgdt((gdt_t*)&gdt);
printf("base: 0x%X limit: 0x%X sizeof: %d ", gdt.base, gdt.limit, sizeof(gdt));
return 0;
}
Now if you run the code more times you should get different values for base address (gdt.base). I my case are:
base: 0xC1813000 limit: 0xFF sizeof: 6
...
base: 0xC1809000 limit: 0xFF sizeof: 6
If I understand well `sgdt' instruction should store 6 bytes content of GDTR at given address (in my case &gdt). I don't understand why I get two different
values for gdt.base.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The same question is appearing in the thread:
http://www.osdev.org/phpBB2/viewtopic.php?p=122469&sid=22578b099869ee17b931ea9946e1c848
Another question to follow is; which distro are you running?
To Mis-quote Obi-Wan Kenobi, "Use the source Luke"! Look at the source code for the system you are running to see where a sgdt instruction is being used.
Also, it is somewhat confusing to understand why this question arrives in a forum about Virtualization.
http://www.osdev.org/phpBB2/viewtopic.php?p=122469&sid=22578b099869ee17b931ea9946e1c848
Another question to follow is; which distro are you running?
To Mis-quote Obi-Wan Kenobi, "Use the source Luke"! Look at the source code for the system you are running to see where a sgdt instruction is being used.
Also, it is somewhat confusing to understand why this question arrives in a forum about Virtualization.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please got to Intel Customer Support email form, http://supportmail.intel.com/scripts-emf/welcome.aspx
for further information on your question
for further information on your question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I realize this thread is very old, but I was interested too and the post on osdev didn't satisfy me. I suspected the behavior you saw was due to your code running on multiple CPUs.
I wrote a kernel module (attached tarball) to test this by running a function on each CPU to dump the GDT. The results (reproduced here for convenience) were consistent with my theory:
CPU #1 and CPU #0 on my system invariably report these two GDT base addresses, respectively. At least in my case, that seems to explain the matter--one GDT per CPU.
I wrote a kernel module (attached tarball) to test this by running a function on each CPU to dump the GDT. The results (reproduced here for convenience) were consistent with my theory:
[plain]CPU 1: Storing GDT... CPU 1: GDT base = 0xc211e000 CPU 1: GDT limit = 0x ff CPU 0: Storing GDT... CPU 0: GDT base = 0xc2018000 CPU 0: GDT limit = 0x ff [/plain]
CPU #1 and CPU #0 on my system invariably report these two GDT base addresses, respectively. At least in my case, that seems to explain the matter--one GDT per CPU.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the information. It is very helpful for me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad to hear it! Do feel free to rate my answer if you found it to be helpful ;-)

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page