[Suggestion]: Recursive map file reading for sym_info and first_diff

[Thar0]

Explain the feature

I'm (again) experimenting with partial linking in OoT, where each spec segment is partially linked into an intermediate file before final link. For example the code segment would be linked into build/segments/code.plf and ovl_kaleido_scope into build/segments/ovl_kaleido_scope.plf. This however makes sym_info and first_diff less accurate with their file reporting:

$ python3 sym_info.py Matrix_MultVec3f
Symbol 'Matrix_MultVec3f' (VRAM: 0x800D1AF4, VROM: 0xB48C94, SIZE: 0xB4, build/gc-eu-mq-dbg/segments/code.plf)
$ python3 sym_info.py KaleidoScope_DrawDungeonMap
Symbol 'KaleidoScope_DrawDungeonMap' (VRAM: 0x8081BB10, VROM: 0xBEAA20, SIZE: 0x1888, build/gc-eu-mq-dbg/segments/ovl_kaleido_scope.plf)

$ python3 first_diff.py --version gc-eu
First difference at ROM addr 0xBA42E0, 0x8081A0B0 is at 0x30 bytes inside 'KaleidoScope_DrawDungeonMap' (VRAM: 0x8081A080, VROM: 0xBA42B0, SIZE: 0x180C, build/gc-eu/segments/ovl_kaleido_scope.plf)
Bytes: 15E101A5 vs 15E101A6
[...]

Each .plf will have it's own .map file in buid/segments/ as well, so it would be nice if these tools could read those map files to find the specific .o file that a symbol originated in.

Edit: I've pushed a branch where I've been experimenting if you want to check it out in context
https://github.com/Thar0/oot/tree/partial-linking

Advantage

It would make the tools more compatible with partial linking.

Disadvantage

Probably nothing, it should be possible to make the default behavior the same as before this feature is added.

Example(s)

I was thinking there could be a dictionary that associates a file suffix with a function resolver(Path) -> Path that maps the input object file path to an output map file path to read:

mapfile_parser.frontends.sym_info.doSymInfo(mapPath, args.symname, plf_file_resolver, map_recurse = {
    ".plf" : (lambda path : path.with_suffix(".map")),
})

Any object file name that matches one of these suffixes in the originally opened map file will have the associated secondary map opened and the filename in that map reported instead.

For example

$ python3 sym_info.py Matrix_MultVec3f
Symbol 'Matrix_MultVec3f' (VRAM: 0x800D1AF4, VROM: 0xB48C94, SIZE: 0xB4, build/gc-eu-mq-dbg/segments/code.plf)

The resolver would transform build/gc-eu-mq-dbg/segments/code.plf -> build/gc-eu-mq-dbg/segments/code.map, read code.map from that path, probably do some sort of vram adjustment since the plf map files start at vram 0, and find
.text 0x00000000000b39b0 0x25e0 build/gc-eu-mq-dbg/src/code/sys_matrix.o
is the object file that contains Matrix_MultVec3f, and display that instead of code.plf

[AngheloAlf]

Sounds like an interesting solution to the partial linking issue. I'll try to play with this idea during this week.

btw, Is plf an standard extension? And what does it mean? "Partial linked file"?
It reminds me to the plfs elf files found on the Gamecube Nintendo Puzzle Collection disc.

$ file Dr_MARIO.plf
Dr_MARIO.plf: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped

Sorry for the late response, I have been busy irl

[Thar0]

.plf isn't standard I don't think, I think a lot of the time when partial linking is used the output objects are also often just .o but I think this is confusing. It's mean to mean "partially linked file" yeah, and is stolen from gamecube terminology.