Fix common ARM32 assembly discrepancies

[abaresk]

This change normalizes the assembly output to remove 2 common sources of diff scoring penalties:

1. Extra padding appearing at the end of function definitions (line 62 in before)
2. Optional destination register omitted by assembler (line 28 in before)

Before: https://pastebin.com/raw/CybxVDe2
After: https://pastebin.com/raw/BMXyfD5s

arm32-discrepancies.zip

[simonlindholm]

Optional destination register omitted by assembler (line 28 in before)

Surprising to hear of this sources of mismatches. Is it different in the binary, e.g. some arm vs thumb thing? Or what causes objdump to either one or the other?

[abaresk]

The issue is with the assembler used by decomp.me. Objdump is correct in disambiguating these 2 cases, as the instructions have different encodings:

1c40: adds r0, r0, #1
3001: adds r0, #1

Unfortunately the assembler used by decomp.me arm-none-eabi-as coerces instances of the former case into the latter.

[simonlindholm]

Can we change the assembler? I worry that this could hide real mismatches from wrong assembler choices, and make them hard to debug when you notice that your build doesn't match. If it's impractical or never comes up in practice outside decomp.me then I guess we could merge this.

(We have a similar case to this in MIPS where li encoded as addiu vs ori show up differently and while confusion vs clarity has been a mixed bag I think it has helped cast light on some real assembler mismatches.)

[abaresk]

That makes sense, I'll report back after investigating the effort on adding proprietary assemblers to decomp.me.

I did some spelunking into modern binutils to see if there's any flags to disable this behavior. Unfortunately, there did not seem to be any -- from what I can tell, this is baked into the relocation-processing stage of the assembler (md_apply_fix()).