`symbol_mappings` works in UI, but ignored for `report generate`?

[emoose]

In SH we have a minor issue with some symbols being built with a random number suffixed at the end, eg. a Screen_BlackBorderDraw func in our code becomes Screen_BlackBorderDraw.64 in the built .o, afaik to do with it being a nested func.

Added something in our objdiff.json generator to detect those and add symbol_mappings for them, in the objdiff UI that seems to link them up fine:

(pls ignore the giant mouse cursor)

In the json from report generate, Screen_BlackBorderDraw doesn't show any percentage for it, leaving decomp.dev to mark it as 0%:

{"name":"Screen_BlackBorderDraw","size":"104","metadata":{},"address":"1348"},
{"name":"Screen_CutsceneCameraStateUpdate","size":"636","fuzzy_match_percent":100.0,"metadata":{},"address":"1452"}

In our objdiff.json the mapping for it looks like:

    {
      "name": "bodyprog/gfx/screen_draw",
      "base_path": "build/src/bodyprog/gfx/screen_draw.c.o",
      "target_path": "expected/asm/bodyprog/gfx/screen_draw.s.o",
      "metadata": {
        "progress_categories": [
          "engine"
        ]
      },
      "symbol_mappings": {
        "Screen_BlackBorderDraw.66": "Screen_BlackBorderDraw"
      }
    },

Wondering if I'm doing something wrong with that, or does report just ignore mappings atm?

Up to now we've just updated our splat sym.txt with the latest suffix GCC decided to use, but that means we sometimes lose some % until someone notices it, any ideas for it would be appreciated.

EDIT: oh there's a PR that might solve our issue with the dot suffixes already, still seems odd that the mappings didn't get used in report though.

[dbalatoni13]

Did my PR fix the mapping in the report?

[emoose]

Yep, with the PR we can just keep the symbol as xxx.0 in our sym.txt, and objdiff matches it up to the actual xxx.123 from the .o fine, no need for the symbol_mappings stuff above, a lot better than needing to keep an eye on .o and update sym.txt each time.

Added build of that PR to our repo at https://github.com/Vatuu/silent-hill-decomp/tree/master/tools/objdiff, many thanks :)

(AFAIK this issue with symbol_mappings not being used for report is still present though, I guess with that we could probably remove the .0 too)