✳flâneur — a map of the web's best reading

Osdev-Notes/99_Appendices/A_Troubleshooting.md at master · dreamportdev/Osdev-Notes

github.com · 613 words · saved by 1 readers

This is a not a definitive solution, but it's an easy to run into. This can commonly be caused by the compiler generating sse (or sse2, 3dnow, or even mmx - I'm just going to refer to them as sse for now) instructions. If the cpu hasn't been setup to handle extended state, it will fault and trigger an #UD. To determine if this is happening, step through your code with gdb, paying attention to any operations that involve an %xmm register. If you have the qemu logs of the crash, you can also examine the kernel binary near the address of the exception RIP. These extensions existed before x86_64, but they were optional. The OS had to support them, and then initialize the hardware into a valid state for these instructions to run. This actually includes the x87 floating point unit as well, and any attempts to use it before executing finit will result in #UD. Now if you're used to programming with more recent cpu extensions, like avx512 for example, you normally have to enable these features

Troubleshooting A collection of unrelated potential issues. Unexpected UD/Undefined Opcode exception in x86_64 This is a not a definitive solution, but it's an easy to run into. This can commonly be caused by the compiler generating sse (or sse2, 3dnow, or even mmx - I'm just going to refer to them as sse for now) instructions. If the cpu hasn't been setup to handle extended state, it will fault and trigger an #UD. To determine if this is happening, step through your code with gdb, paying attention to any operations that involve an %xmm register. If you have the qemu logs of the crash, you can

Explore this link on the map →

related reading