D4d4

Summary

D4D4 A co-worker of mine was looking at some disassembled ARM code the other day, and discovered something weird. Lots of d4d4 instructions, scattered about. LLVM’s objdump says this is a relative branch to -0x58. The weird part is that they were always unreachable. Experiments Here’s an example in a minimal reproducer I wrote: 00020100 <one>: 20100: 4770 bx lr 20102: d4d4 bmi 0x200ae <__dso_handle+0x100ae> @ imm = #-0x58 That bx lr right before the d4d4 branches to the link register. In other words, it returns. Here’s the C code that goes with this function: #include "mod.h" static void one(void) { return; } int main(void) { void *fn; fn = one; use_ptr(fn); return 0; } The use_ptr function is declared in mod.h (defined in mod.c), and what it does with the pointer is not important. You can see that there’s a function called one, and that function just returns. Thus bx lr being the only thing. But why is there an extra d4d4 after it in the disassembled object code? My first thought was that it was there for alignment. Of course, Thumb instructions are 16 bits and maybe functions need to be 32-bit aligned. Weird that it would use a branch to a real relative address instead of a nop or something that would cause a fault, but let’s try expanding the experiment. code: static void one(void) { return; } static void two(void) { return; } int main(void) { void *fn; fn = one; use_ptr(fn); fn = two; use_ptr(fn); return 0; } And the disassembly: 000200f4 <main>: 200f4: b580 push {r7, lr} 200f6: 466f mov r7, sp 200f8: 4803 ldr r0, [pc, #0xc] @ 0x20108 <main+0x14> 200fa: f000 f80b bl 0x20114 <use_ptr> @ imm = #0x16 200fe: 4803 ldr r0, [pc, #0xc] @ 0x2010c <main+0x18> 20100: f000 f808 bl 0x20114 <use_ptr> @ imm = #0x10 20104: 2000 movs r0, #0x0 20106: bd80 pop {r7, pc} 20108: 11 01 02 00 .word 0x00020111 2010c: 13 01 02 00 .word 0x00020113 00020110 <one>: 20110: 4770 bx lr 00020112 <two>: 20112: 4770 bx lr 00020114 <use_ptr>: 20114: 4770 bx lr Not only does the compiler not feel t...