Sonic CD Gems Collection Linker Disassembly Dumps

So, I've been digging at those ELF files for the Gems Collection version of Sonic CD. While objdump could be used to extract function and variable names, I noticed that it wasn't able to parse the .debug sections. The thing is that, there were definitely more symbols to extract, such as structure member names.

Today, I did some more digging, and found this thread, which actually talked about my very issue, but for DDRMAX2. The very last post then took me to this post, which showed that someone successfully managed to extract data from the .debug section, and provided a batch script on how they did it.

Gems Collection so happened to have been compiled and linked with the same tools as DDRMAX2, and I found an archive of those tools on archive.org, with cracks. So, I installed them and ran the Sonic CD ELF files from the PS2 version through the linker's disassembler, and...

It worked.

It's pure beauty. A much more complete dump of symbols with disassembled code from Sonic CD is now available.

 

I'm not sure what's going on, but tools like IDA or objdump cannot parse the .debug section, hence why I even went through this process, even though apparently it is in a DWARF format. objdump was able to retrieve the filenames and line numbers from there, but for some reason couldn't recognize anything else. They're able to parse all the other symbols from other sections, though.

 

There's not much I can really do with those, as the only ELF files that I can really find don't really seem to be directly related to the games themselves, and even then, they appear to have their symbols stripped.

 

Afraid that their debug symbols are also stripped out as well.

 

I do link to the archive of the IDE and compiler/linker in the first post, so you may wanna check that out.

 

The "mcwps2r3" one.

 

You can run the linker separately. It's in the "PS2_Tools/Command_Line_Tools" folder in the installation path.

 

The -S option produces an output file in mwldps2.

 

So, upon digging through this more after finding the time to do so... not only are there more symbols that can be found than what was initially found, but also every function's arguments, their local variables, the structures used, and other information attached to them, like their types, and all kinds of other stuff that was used for debugging.

Here's an excerpt:

Code (Text):

1. 00011781:<116>TAG_compile_unit
2. 00011787    AT_sibling(000118f9)
3. 0001178d    AT_low_pc(010075e0)
4. 00011793    AT_high_pc(010077a0)
5. 00011799    AT_stmt_list(00003e18)
6. 0001179f    AT_language(LANG_C)
7. 000117a5    AT_producer(MW MIPS C Compiler)
8. 000117ba    AT_name(C:\project\GEMS\application\SonicCD\src\ps2\main\ENEMY.C)
9. 000117f5:<107>TAG_global_subroutine
10. 000117fb    AT_sibling(000118f5)
11. 00011801    AT_low_pc(010075e0)
12. 00011807    AT_high_pc(010077a0)
13. 0001180d    AT_fund_type(FT_void)
14. 00011811    AT_global_refs_block(<8>8f fc 00 00 b2 fc 00 00 )
15. 0001181d    AT_restore_S0(<6> OP_BASEREG(29) OP_DREF8)
16. 00011827    AT_restore_S1(<12> OP_BASEREG(29) OP_CONST(16) OP_ADD OP_DREF8)
17. 00011837    AT_return_addr(<12> OP_BASEREG(29) OP_CONST(32) OP_ADD OP_DREF8)
18. 00011847    AT_restore_SP(<11> OP_REG(29) OP_CONST(64) OP_ADD)
19. 00011856    AT_name(ka_move)
20. 00011860:<45>TAG_formal_parameter
21. 00011866    AT_sibling(0001188d)
22. 0001186c    AT_mod_u_d_type(<5>MOD_pointer_to (0000fcd8))
23. 00011875    AT_location(<11> OP_BASEREG(29) OP_CONST(48) OP_ADD)
24. 00011884    AT_name(pActwk)
25. 0001188d:<24>TAG_lexical_block
26. 00011893    AT_sibling(000118f1)
27. 00011899    AT_low_pc(010075e0)
28. 0001189f    AT_high_pc(010077a0)
29. 000118a5:<42>TAG_local_variable
30. 000118ab    AT_sibling(000118cf)
31. 000118b1    AT_mod_u_d_type(<5>MOD_pointer_to (0000fcd8))
32. 000118ba    AT_location(<5> OP_REG(17))
33. 000118c3    AT_name(pPlayerwk)
34. 000118cf:<30>TAG_local_variable
35. 000118d5    AT_sibling(000118ed)
36. 000118db    AT_fund_type(FT_signed_short)
37. 000118df    AT_location(<5> OP_REG(16))
38. 000118e8    AT_name(d0)

The numbers on the left are basically the "location" of the information listed on that line. "AT_fund_type" and "AT_mod_u_d_type" indicate a type of variable. "MOD_pointer_to" means that it's a pointer, and they can be repeated to indicate the number of layers (i.e. "MOD_pointer_to MOD_pointer_to FT_char" is the same as char**). Any time that has a hex number instead is pointer to one of those location numbers found on the left, and that will give you the actual type info. "AT_name" is the symbol name, of course. In the "TAG_compile_unit" section, the name is the full path name of the source file that the subsequent sections were compiled from. Unfortunately, it seems that structure names were not kept...? They're just labelled as "anonX". I wonder if I can write myself a quick tool to convert all of this info into something more legible... or maybe something already exists, considering this is definitely DWARF.

EDIT: It's DWARF v1... apparently that's why there's been some trouble, because some tools don't even support it.
EDIT 2: Found a tool that actually does what I wanted to do a bit. Will come back with dumps soon-ish.