Data % seems incorrect?

[emoose]

TL;DR: seems there's issues with the jtbl data inside .rodata not being counted after we've matched the code for it (since cc itself won't create jtbl_* syms for the switches?), which tanks the .rodata totals in most files since objdiff won't find a jtbl_* sym to compare against, and seems to end up treating the whole .rodata as unmatched in a lot of files :/

No idea why we're affected by this when other projects seem to have reliable data % though - might be to do with the symbol visibility (jlabel/dlabel/etc?), but haven't had any luck trying to mess with that.

---

Tried looking into moving over data to C, looks like we do have quite a bit done already but the % tracker isn't counting it for some reason?

eg. bodyprog_800706E4.c is shown at 0% data
https://decomp.dev/Vatuu/silent-hill-decomp?category=engine&unit=bodyprog%2Fbodyprog_800706E4

Says 4.68KB of data there, .rodata of that file comes to 4348 bytes, and .bss is 328, so guess those added together is the count it uses.
But the .rodata is mostly jtbls of funcs we've matched, and a couple small vars we also matched in the .c, a lot of .bss is also matched in the .c too..

Not really sure how objdiff is deciding what data is matched or not, noticed the .rodata.s has some nonmatching D_800C4618 line above each one, seems that inserts a [var name].NON_MATCHING symbol into the .o that's built from it.

Guessing that sym gets added to the expected .o files, then compared against the .o built from our .c, if the builds .o has that symbol then it shows splat config isn't using .rodata from the .c but using the non-matched rodata.s instead - but afaik all our splat splits do pull from the .c, so can't see why they'd still be marked non-matching :/

If anyone has any ideas about it let me know, I'll try looking into it more soon too..

[emoose]

So in report.json bodyprog_800706E4 has the total_data size, but doesn't have any matched_data_percent / complete_data_percent (which was present in other files that have matched data on decomp.dev)

            "measures": {
                "fuzzy_match_percent": 100.0,
                "total_code": "66140",
                "matched_code": "66140",
                "matched_code_percent": 100.0,
                "total_data": "4684",
                "total_functions": 65,
                "matched_functions": 65,
                "matched_functions_percent": 100.0,
                "total_units": 1
            },

Looking at symbols in expected .o with nm expected/USA/bodyprog/bodyprog_800706E4.s.o, we get the NON_MATCHING syms from .bss:

00000134 B g_Player_IsRunning
00000134 B g_Player_IsRunning.NON_MATCHING
000000f0 B g_Player_IsShooting
000000f0 B g_Player_IsShooting.NON_MATCHING
000000dc B g_Player_IsSteppingLeftHold
000000dc B g_Player_IsSteppingLeftHold.NON_MATCHING
000000b0 B g_Player_IsSteppingLeftTap
000000b0 B g_Player_IsSteppingLeftTap.NON_MATCHING
000000de B g_Player_IsSteppingRightHold
000000de B g_Player_IsSteppingRightHold.NON_MATCHING
000000b2 B g_Player_IsSteppingRightTap
000000b2 B g_Player_IsSteppingRightTap.NON_MATCHING

and in the symbols from our build, we have same syms without NON_MATCHING:

00000134 B g_Player_IsRunning
000000f0 B g_Player_IsShooting
000000dc B g_Player_IsSteppingLeftHold
000000b0 B g_Player_IsSteppingLeftTap
000000de B g_Player_IsSteppingRightHold
000000b2 B g_Player_IsSteppingRightTap
000000b4 B g_Player_IsTurningLeft
000000b6 B g_Player_IsTurningRight

So no idea why it's not counting them...

Also shows the match % of each section too, which has .bss at 70% (but should be 100?), and rodata very low, likely because our .o is missing jtbl_ symbols:

            "sections": [
                {
                    "name": ".bss",
                    "size": "332",
                    "fuzzy_match_percent": 70.03012,
                    "metadata": {
                    }
                },
                {
                    "name": ".data",
                    "fuzzy_match_percent": 100.0,
                    "metadata": {
                    }
                },
                {
                    "name": ".rodata",
                    "size": "4352",
                    "fuzzy_match_percent": 0.00017655823,
                    "metadata": {
                    }
                },
                {
                    "name": ".text",
                    "size": "66140",
                    "fuzzy_match_percent": 100.0,
                    "metadata": {
                    }
                }
            ],

So it can see how much of .bss/.data/.rodata is matched, but decides not to output any matched_data_percent, weird.

[emoose]

In objdiff code looks like matched_data_percent is always worked out, but wonder if maybe when it's too small it gets skipped from json.. maybe jtbl stuff is just pulling percentage too low for it to get written out.

Not sure how we're meant to handle that, compiler doesn't create jtbl_ symbols but splat always makes nonmatching for them, haven't seen anyone else mention issues with jtbl on objdiff issues neither...

E: tried removing the NON_MATCHING syms for jtbls but same issue.. wonder if it's the jtbl symbols themselves that cause it.
I noticed that splat asm_jtbl_label_macro is set to jlabel (visibility = local), but in the rodata.s the jtbl uses dlabel (visibility = global), can't figure out why though :/

[IWILLCRAFT-M0d]

Just noticed this issue lol

I think Objdiff is not actually counting all data either because the script intentionally skips all files that only contains data.

Also many files should have a lower count as they are not being properly compared, for example, bss segment may not be properly counted due the way how padding is handled as we could have a 4 bytes variable which we defined as a u8 but due padding we defined 3 s8 variables to fill the gap, but non of them are assigned in the symbols