ARM - Issues related to jumptables and constant pools

[Yanis002]

This differ has some issues related to ARM, I'll try to detail them as best as I can:

1. jump tables: most of the times the offsets are showed as a diff while it's matched (like here: https://decomp.me/scratch/5hltl), in other cases the diff hangs with Diff error: Error dumping target assembly: Diff error: Error preprocessing dump: int() can't convert non-string with explicit base (like here: https://decomp.me/scratch/QVigU or here https://decomp.me/scratch/j4cnd, the target asm was included on those scratches), the second issue being the more concerning one
2. constant pools: it's always showing a diff, even if it's matched, and each constant pool loads in the code is highlighted as a diff (see https://decomp.me/scratch/Ojoei)

It seems ASM uploads doesn't do anything different (I only tried for the jumptable error one by making a scratch from the website: https://decomp.me/scratch/kjNWA)

just in case it helps, here's the object files from my project (https://github.com/zeldaret/st, hopefully I did it right): objects.zip, constant_pool_jumptables-diff is for https://decomp.me/scratch/5hltl and jumptables-errors is for https://decomp.me/scratch/QVigU

I'm not sure what else I can provide but feel free if there's anything I can do to help, btw this is all using THUMB mode but it's the exact same issues with ARM mode

[simonlindholm]

I pushed 8fc8225 to make the preprocessing a bit more resilient, which should fix the "diff error" issues at least.

[simonlindholm]

The cause of the constant pool diffs (and probably underlying cause for the crashes, too) is that the target ELF file does not mark the constant pools as data, so they disassemble as code in the target and as data in the attempted match, and asm-differ treats these differently even though it hides the difference visually. You can see it if you manually objdump the .o files:

$ arm-none-eabi-objdump -dzr target.o | rg -B1 data_ov024_020d8660
 7f8:	0000 0000                                   ....
			7f8: R_ARM_ABS32	data_ov024_020d8660
$ arm-none-eabi-objdump -dzr current.o | rg -B1 data_ov024_020d8660
 110:	00000000 	.word	0x00000000
			110: R_ARM_ABS32	data_ov024_020d8660

GNU as is supposed to handle this automatically, by emitting local symbols named $d<something> and $t<something> as markers: https://www.sourceware.org/binutils/docs/as/ARM-Mapping-Symbols.html. Locally when I use arm-none-eabi-as (ver 2.45.50) on test files I see this happen correctly. I don't know why it's not happening for you here. Maybe some asm/macro nuance, or difference in assemblers used.

[AetiasHax]

Hi, I'm the author of dsd, the binary splitter that was used here. After some digging, I found that the cause of the constant pool diffs was not the lack of mapping symbols, but rather that dsd generates pool constant symbols with STT_OBJECT. objdump doesn't disassemble symbols of type STT_OBJECT, leading us to a mismatch between constant pool disassemblies.

This is something I'll be fixing on my end, probably by using STT_NOTYPE or by excluding pool constant symbols entirely, which should take care of point 2. 🙂