Comment by nneonneo

I'm confused, because d4d4d4d4 doesn't look like a trap in 32-bit ARM either:

  0x0000000000000000:  D4 D4 D4 D4    ldrble sp, [r4], #0x4d4

(from https://shell-storm.org/online/Online-Assembler-and-Disassem...)

This is "load byte at [r4 + 0x4d4] into sp, then add 0x4d4 to r4, but only if the condition flags signal a comparison result of less-than-or-equal". It is unlikely to be a useful instruction, since it causes the stack pointer register SP to be less than 0x100 (if [r4+0x4d4] is even a valid address), but it sure as heck isn't a trap. And, if the condition flags are right, this is just a NOP instruction.

As far as I can tell, 0xd4d4d4d4 is only invalid on AArch64, and only because it happens to not yet be a defined instruction. 0xd4 does in fact introduce an exception generation instruction, but 0xd4d4xxxx is invalid as it is an unallocated combination of bits. However, nothing prevents this from being a defined instruction in the future, which makes 0xd4d4d4d4 a really bad choice as it could turn out to be a valid instruction in the future that performs an unexpected operation.

In all, 0xd4 looks like a terrible choice for a padding byte for any ARM architecture, so it's a real mystery why this specific choice was made.