Quote:
Originally Posted by Bruce Abbott
To get an identical binary you have to reproduce the nop. If you modify the binary then you need to know whether the nop is an actual opcode or padding for alignment.
Not always. Take the following code for example:-
Code:
r09648:
move.w 20(A5),D0
ext.l D0
sub.l #$00000001,D0
blt.s r096a6
cmpi.l #$00000004,D0
bgt.s r096a6
asl.l #1,D0
jmp *+4(PC,D0.w)
bra.s r0966c
bra.s r09688
bra.s r0966c
nop
r0966c:
move.l 26(A5),-(A7)
pea a09cff ; "Minimum=%d."
move.l l0ee7e,-(A7)
jsr r11a0c
Is the nop for alignment, or is it code? To answer that question you have to figure out what the code above it is doing - in this case it's a computed jump and the nop is one of the destinations. Changing this nop to dc.w 0 would be fatal.
Granted you don't see this very often. My disassembler assumes that nops are not code if they are found outside a labeled code block, but sometimes there's no label. If there is also 'data' before the nop then it gets tricky (at least if you want an accurate disassembly, rather having blocks of code shown as data). My disassembler shows it as a nop rather than cnop because it might actually be code.
dc.w 0 can also be tricky to identify. Luckily the instruction ori.b #x,d0 is not often found at the start of a code block, and if the following word's value is >255 then it's almost certainly not code. dc.l 0 is easier because ori.b #0,d0 is a useless instruction. |
Right. dc.w 0 is not perfect for padding, but is better than nop. Perhaps perfect for padding can be $4AFC (Illegal) opcode. Anyway, i remember some code/sources which used cnop 0,8 or cnop 0,16 or even more bytes padded with Nq (nop) and some data which used cnop 0,2 or even, padded with $4E byte.