Preservation of types + output of global variable addresses
I noticed that dwarf2CPP doesn't preserve signed types being explicitly declared as such (for example, "signed char" being just "char," with the "signed" being discarded).
It'd be cool if we had the option, at least, to preserve this explicitness - irrespective of if redundant or not. I could see that as something a stickler would find useful if say using this as a beginning stepping stone for decompilation efforts.
Also wondering if it would be possible to make it so variables that are global can have their address (AT_location having a location atom of OP_ADDR?) value printed in the output - I find this would be REALLY useful with regards to reverse engineering Playstation2 games, particularly with games across a series, where a lot of the same types are used, but might be in different places (and whom might be defined in the leftover debugging data for one game, but not for another). Specifically, I think it will help in being able to hunt down globals that will exist in multiple games (but might be in the leftover debugging data for one, but not another), if that makes ANY SENSE at all (uncaffeinated dumbass posting here, haha).
Also wondering if there would be any use for trying to make functionality that could attempt to seek out DWARF data even if the associated header information at the beginning of an ELF is missing - some examples of where this seems to be the case (DWARF debugging data existing, but not being recognized by Dwarf2CPP as a result) being the DEMO DISC to DDRMAX2 -DanceDanceRevolution-, and DancingStage Megamix. (I wonder if there might be more examples out there for where such a functionality might come in handy.)
I'm working on a GUI tool intended to replace dwarf2cpp with a lot of customization features already implemented:
By default signed char is represented as "signed char" and char is represented as "char", but you can also rename the fundamental types to whatever is appropriate for your needs. The reason signed char is just "char" in dwarf2cpp is that the game I was mainly testing it with made no distinction between char and signed char in the DWARF data/symbols, so I figured char would be correct in more situations than signed char (e.g. const signed char* to represent a string looks kinda strange). I realize that not all compilers output DWARF data in this way, though, and preserving explicitness is something I realize should be respected.
Printing addresses of variables is also implemented, they're written as a comment after the variable declarations. Many other comments are also printed, such as class sizes, struct member offsets, function argument locations, etc. and these can all be toggled on/off in the GUI.
The ability to select a specific section in the ELF file is also planned in case the tool doesn't auto detect it.
Dude! That sounds AWESOME! I can't wait.
One thing I have noticed in trying my hand at making something that can read ELF executables and locate DWARF data (though I don't know if I can call this reliable by any means*) is that it seems the section headers with the sh_type of DT_MIPS_FLAGS (0x70000005) are the ones that will (OR won't if it's been stripped out) contain DWARF DIE information.
* I say that IDK if it is reliable even though I did run at least a dozen executables for a dozen DDR titles that have leftover DWARF 1 data through my program to see if it located DWARF DIEs, and returned an accurate count of DIE information, and saw that it did - maybe that's just me overthinking things though haha)