jump table binaries

[CR3Swapper]

64bit msvc jump table https://godbolt.org/z/neMa17bPe

[CR3Swapper]

32bit msvc jump table https://godbolt.org/z/cz8EPsdvG

[CR3Swapper]

big indirect jmp table https://godbolt.org/z/5axrWcKdG (msvc 64bit)

[CR3Swapper]

big indirect jmp table https://godbolt.org/z/5MTzoE4h4 (msvc 32bit)

[CR3Swapper]

unbounded jump table https://godbolt.org/z/bdsor4YnG clang

[CR3Swapper]

unbounded jump table https://godbolt.org/z/aY5zaaPEf msvc using __assume(0);

[CR3Swapper]

Notes

Im going to dump some information about jump tables that ive observed from research.

There are 3 types of jump tables

• multi level jump tables (aka indirect jump tables).
• single level jump tables with different variations.
• unbounded jump tables (there is no comparison for base case since the compiler is able to determine all paths).

llvm vs msvc

seems like llvm puts its jump tables outside of the text section by default. MSVC keep them inside of the text section and close to the function. I think msvc does this for performance reasons (cache locality?). Theres an option for msvc to put jump tables into the rdata section though (https://learn.microsoft.com/en-us/cpp/build/reference/jump-table-rdata?view=msvc-170).

LLVM generated jump tables seem to compute the destination address by taking the address of the jump table itself and then adding it to the entries inside of the table. This is different than msvc which uses image base LEA. Also i have yet to get LLVM code to generate multi level jump tables.

Rust compiler and its magic

The rust compiler does a lot of compile time analysis of the source code. When you write a match case in rust that satisfices all possible cases the compiler will attempt to create an unbounded jump table. Very cool but also creates an issue with determining the length of the table in a "safe" manner.

[CR3Swapper]

done, parsed all jtable varients that we care for.