>
> This code (to test invd from user mode) simply produced a core-dump.
> This is what the trap should have done. I tried this first at home
> on a '486 and then tried it here (over the network) on a Pentium.
He's perfectly correct here. I'm running a Pentium 133, stepping 12.
I compiled this. It segfaulted. I ran it through gdb, and found this:
Program received signal SIGSEGV, Segmentation fault.
0x80484f3 in main ()
(gdb) backtrace
#0 0x80484f3 in main ()
#1 0x804848b in ___crt_dummy__ ()
(gdb) disassemble
Dump of assembler code for function main:
0x80484f0 <main>: pushl %ebp
0x80484f1 <main+1>: movl %esp,%ebp
0x80484f3 <main+3>: invd
0x80484f5 <main+5>: pushl $0x8048568
0x80484fa <main+10>: call 0x80483c8 <printf>
0x80484ff <main+15>: addl $0x4,%esp
0x8048502 <main+18>: pushl $0x8049640
0x8048507 <main+23>: call 0x80483d8 <fflush>
0x804850c <main+28>: addl $0x4,%esp
0x804850f <main+31>: movl %ebp,%esp
0x8048511 <main+33>: popl %ebp
0x8048512 <main+34>: ret
I'll go bug hunting if someone will tell me where in blazes this trapper
is supposed to be. I ran a grep on the entire kernel source tree for
'invd' and found one reference in process.c, which was a comment in a list
of opcodes for a real mode context switch.
What should be the correct behavior for the invd wrapper? Perhaps just
return after doing absolutely nothing? I can't see much sense in allowing
user-mode processes to invalidate the processor cache. Such a thing would
be a security hole, and would be realized the first time someone got the
bright idea to make a bunch of programs which loop a 'invd' continuously
(I'm assuming that would shoot performance to hell). Internally the
kernel needs to make use of the instruction for things such as mode
switches, for obvious reasons. I don't see what a user process would need
it for. I may be missing something, though.
> #include <stdio.h>
>
> main()
> {
> __asm__ __volatile__(
> "invd" );
> printf("Was not killed!");
> fflush(stdout);
> }