Call gates

[chris]

What exactly is the difference between Call Gates and Trap Gates?

[Brendan]

Hi,

What exactly is the difference between Call Gates and Trap Gates?

The main difference is that call gates allow parameters to be transferred on the stack (e.g. the top N dwords from the user level stack can be automatically copied to the kernel's stack). This is intended for the calling conventions in high level languages. With trap gates all parameters must be passed in registers.

Another difference is that trap gates belong in the IDT, while call gates go in the GDT or LDT.


Cheers,

Brendan

[Dreamsmith]

The main difference is that call gates allow parameters to be transferred on the stack (e.g. the top N dwords from the user level stack can be automatically copied to the kernel's stack). This is intended for the calling conventions in high level languages. With trap gates all parameters must be passed in registers.

Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.

[chris]

Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.

Then why not simply use call gates?

[RedMan]

A new stack? I thought there was only one stack, what?s up with the new stack?

[Candy]

A new stack? I thought there was only one stack, what?s up with the new stack?

Each thread has its own stack, each thread also has its own kernel stack. Using some tricks you can avoid having two stacks (such as my OS will do when it gets to userlevel stuff), but usually you have both a kernel stack and a userlevel stack.

[RedMan]

Oh, is this something "special magic autmaticlly" or I decide if I?d like to have that by changing the stack pointer by myself?

[Candy]

Oh, is this something "special magic autmaticlly" or I decide if I?d like to have that by changing the stack pointer by myself?

no, this is fully automatic. You specify them all in your TSS (you must have one of those too), and then you always swap them, using Intels methods at least.

In AMD64 this is fixed, you can choose whether to swap the stack, and using SYSCALL/RET the default is NOT to. Upon interrupt one of a number of stacks can be used, all specified in the new-style TSS (which doesn't hold the task info but more the system state, such as the stacks).

[Dreamsmith]

Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.

Then why not simply use call gates?

Excellent question. The answer would be, because trap gates take less space and are faster. Now, if I was using a trap gate, then manually copying the parameters between stacks, that would be silly, might as well use a call gate in that case. But I don't copy parameters between stacks. Instead, I just look at them in place on the old stack. I don't use a call gate because I don't want to waste time copying parameters between stacks when I don't need to.

Of course, for this to work, you need access to the caller's stack, but for my kernel that's a given. It would only be an issue if you're just routing the request to some user-thread, ala a microkernel approach, in which case you would need to copy the parameters.

[RedMan]

Stupid question, but how does the CPU know how many arguments to pass to the new stack?

[Dreamsmith]

You specify that when you create the call gate. Note, varargs is not an option...

[chris]

Actually, that's not true. I use trap gates for my OS system calls, and I pass all parameters on the stack. A more accurate statement would be, call gates automatically copy parameters to the new stack for you, whereas trap gates do not.

Then why not simply use call gates?

Excellent question. The answer would be, because trap gates take less space and are faster. Now, if I was using a trap gate, then manually copying the parameters between stacks, that would be silly, might as well use a call gate in that case. But I don't copy parameters between stacks. Instead, I just look at them in place on the old stack. I don't use a call gate because I don't want to waste time copying parameters between stacks when I don't need to.

Of course, for this to work, you need access to the caller's stack, but for my kernel that's a given. It would only be an issue if you're just routing the request to some user-thread, ala a microkernel approach, in which case you would need to copy the parameters.

Makes sense to me, thanks.