We now have generation of an import library for linking against the Xbox
kernel, linking together an .exe, and converting it to an .xbe via cxbe.
Some further development of tooling aside (including filling in some
features in cxbe to better match the original JSRF executable), all that
remains now is to write decompiled code.
Ghidra sometimes identifies random numbers as pointers, which trips up
our mangler script when it encounters them as they generally have no
type information. We now use heuristics to ignore such references.
We used the flimsy heuristic of a reference from non-executable memory
to try to guess at whether a reference was a vtable, but now we just
check whether it's been named as a vtable.
This introduces its own issues, but without namespaces, symbol names end
up repeated and delinking fails. The delinked symbols also end up
without namespaces, introducing yet more problems. This is an
improvement for now, but we'll need proper namespace importing into
Ghidra at some point.
There have been cases of the "decompilation progress" metric being
confused for total progress, so a new figure has been added (in bold)
roughly estimating the total progress by multiplying the other two
together.
The /O2 used before was actually a preset for a bunch of more specific
flags, which are now written explicitly for clarity and easier
modification later.
JSRF appears to have it disabled despite other optimizations. Even if
it was enabled, anyways, we'd still be decompiling the post-inlining
functions and wouldn't want any further inlining to take place (we want
the compiler to compile each function the way we write it).
The change in the previous commit was a silly case of not thinking
things through, not realizing that the .data range moved to Core.obj was
nowhere near the beginning of the section as it should be. g_game has
been moved back into Jet2.obj (time will tell if this is correct) and a
missed data strucure at the beginning of .data (where it ought to be)
now makes up Core.obj's .data portion.
objdiff assumes that all symbols in executable memory sections are code,
which led to misbehaviour due to .rdata and .data being marked as
executable in JSRF. We now set these sections to non-executable in
Ghidra to work around this.
