inusualz / dadosod Goto Github PK

i might be dumb for asking this so please forgive me can this work for homebrew applications too

Hi, in melee we are looking for a way to dump the binary we've built back to asm. However, with the current implementation of your disassembly, we lose our file splits and symbol names in the process. We would like to preserve the file tree of our source files in the output asm, and use our symbol names (which are present in the .elf) instead of symbols generated based on address.

I see that "Library Splitting" is a planned feature in your README. What would be involved in implementing these features? I wouldn't mind writing them myself, but I'm not familiar with Rust or with your codebase so it would take me some time to adjust.

Thanks for your consideration.

Hi! I've recently picked up a mod project that was abandoned by the previous person who had been working on since it had been sitting for so long and nobody else seemed like they would be picking it up. He's made several custom modifications to the 'main.dol' file for the game, but there is no documentation or decompiled files that were left behind before he deleted his accounts. My solution is to decompile the vanilla and modified versions of the .dol file and compare them via diffing to see if I can locate the decompiled modified code in order to better understand it, but I've hit a bit of a snag.

When I ran dadosod on the vanilla main.dol, the file decompiled with no issues. However, when I tried to decompile the modified main.dol, I get this error code:

thread 'main' panicked at 'range end index 4731024 out of range for slice of length 4685072', library\core\src\slice\index.rs:73:5
stack backtrace:
   0:     0x7ff76263da3f - <unknown>
   1:     0x7ff76264dffa - <unknown>
   2:     0x7ff76263a539 - <unknown>
   3:     0x7ff76264009b - <unknown>
   4:     0x7ff76263fc8e - <unknown>
   5:     0x7ff762640691 - <unknown>
   6:     0x7ff76264054d - <unknown>
   7:     0x7ff76263e347 - <unknown>
   8:     0x7ff762640229 - <unknown>
   9:     0x7ff762654995 - <unknown>
  10:     0x7ff76264f7db - <unknown>
  11:     0x7ff76264c909 - <unknown>
  12:     0x7ff76264cb09 - <unknown>
  13:     0x7ff762654a59 - <unknown>
  14:     0x7ff76261e359 - <unknown>
  15:     0x7ff76262078f - <unknown>
  16:     0x7ff76261cc68 - <unknown>
  17:     0x7ff76261e476 - <unknown>
  18:     0x7ff76261c3fc - <unknown>
  19:     0x7ff7626353de - <unknown>
  20:     0x7ff76261d347 - <unknown>
  21:     0x7ff762652a3c - <unknown>
  22:     0x7fff7ec37344 - BaseThreadInitThunk
  23:     0x7fff80c426b1 - RtlUserThreadStart

My guess is that I may need to compile dadosod with modified code to allow the larger range, but I'm not entirely sure how I would do this. Any help or suggestions would be greatly appreciated! I am very new to all of this and am learning as I'm going along.

Later MWCC compilers for the Wii shifted the order of bss sections around such that bss comes after sbss2, rather than between the data and sdata sections. Currently, dadosod breaks when trying to disassemble DOLs built with this ordering; in particular, it misidentifies the presence of a file section between dtors and rodata, and fails to output the sbss2 and bss sections altogether.

Failed to parse instruction at text.s line 1098614: stmw r4, lbl_805F96F0@sda21(r2)

Sample

/* 8039CAC8 00396388  7C 12 42 A6 */	mfspr r0, 274
/* 8039CACC 0039638C  90 02 00 0C */	stw r0, lbl_805F96EC@sda21(r2)
/* 8039CAD0 00396390  BC 82 00 10 */	stmw r4, lbl_805F96F0@sda21(r2)
/* 8039CAD4 00396394  7F 7A 02 A6 */	mfspr r27, 26
/* 8039CAD8 00396398  7F 88 02 A6 */	mflr r28

lbl_805F96F0 does not exist within the text.s
Only within sdata.s

lbl_805ECD50:

	# ROM: 0x575650
	.4byte lbl_805F96F0
	.4byte 0

Proposal: add flag/support for skip/nop patching if the lbl does not exist