Change executable section flags to please objiff

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.

contributing.md

@@ -76,6 +76,11 @@ asked whether you want to run analyzers; say yes.  Afterwards, simply clicking
 "Analyze" in the analysis options window without changing anything is fine, and
 the analysis will probably take a couple minutes.
 
+There's a small oddity that needs fixing: certain parts of memory are marked as
+executable where objdiff doesn't expect them to be, which will mess up our
+diffs.  To correct this, open the memory map (`Window > Memory Map`) and
+uncheck the "X" column for `.rdata`, `.data`, and `DOLBY`.
+
 Now we'll import symbols from the JSRF decompilation repository.  After running
 the analysis, open the script manager (`Window > Script Manager`) and select
 the "Data" folder in the left pane.  Double click the script titled
@@ -145,9 +150,12 @@ automatically.  Otherwise, one has to click on one of the corresponding
 functions in one pane and the other function in the other pane to tell objdiff
 to link them.  Common cases of this are class methods (the names won't match)
 and implicitly generated functions, such as exception handling code placed in
-`.text$x` in the recompiled object file.  Keep in mind that objdiff also
-appears to misidentify many symbols as functions even if they're data in e.g.
-the `.data` section, which confuses the overall match percentage somewhat.
+`.text$x` in the recompiled object file.  Keep in mind that objdiff's matching
+does not appear fully reliable in some cases, particularly when diffing data
+with external pointers (which appear as `?? ?? ?? ??`) that aren't explicitly
+marked as non-matching but still somehow reduce the match percentage, so you'll
+have to use a tiny amount of judgement to determine when you actually have a
+match.
 
 Clicking on a function that's been linked across both object files shows a diff
 of the disassembly of both versions of the function, with any differences

decompile/objdiff.json

@@ -14,8 +14,11 @@
         "source_path": "src/JSRF/Jet2.cpp"
       },
       "symbol_mappings": {
-        "_main_handler": "$L522",
-        "_main_handler_unwind1": "$L514"
+        "[.rdata-0]": "[.xdata$x-0]",
+        "_main_funcinfo": "$T519",
+        "_main_handler": "$L523",
+        "_main_handler_unwind1": "$L515",
+        "_main_unwindmap": "$T525"
       }
     }
   ]

readme.md

@@ -3,7 +3,7 @@ A matching decompilation of the Xbox game Jet Set Radio Future.
 
 ## Progress
 - Delinking progress: 0.008% (205 out of 2574172 bytes in XBE address space)
-- Decompilation progress: 100% (6 out of the 6 symbols delinked so far)
+- Decompilation progress: 100% (3 out of the 3 functions delinked so far)
 
 ## Roadmap
 The approach of this decompilation is to: