I'm trying to disassemble libnickel.so found on my kobo (~12Mb) with arm-linux-gnueabi-objdump on a linux machine. The file format is correctly detected as elf32-littlearm, and all opcodes are 32-bit as expected for ARM; but suddenly output aspect changes, showing non-32-bit opcodes:
=== CORRECT ARM CODE ===
...
4dc288: 447b6802 ldrbtmi r6, [fp], #-2050 ; 0xfffff7fe
4dc28c: 4a06b11a bmi 6886fc <_ZN20N3BookInfoController12onBookParsedERK6Volume+0x54>
4dc290: b103589b ; <UNDEFINED> instruction: 0xb103589b
4dc294: e8bd4798 pop {r3, r4, r7, r8, r9, sl, lr}
4dc298: f7ff4008 ; <UNDEFINED> instruction: 0xf7ff4008
4dc29c: bf00bfb3 svclt 0x0000bfb3
4dc2a0: 00627fee rsbeq r7, r2, lr, ror #31
4dc2a4: 00682ef2 strdeq r2, [r8], #-226 ; 0xffffff1e ; <UNPREDICTABLE>
4dc2a8: 0001d51c andeq sp, r1, ip, lsl r5
==== INCORRECT CODE (?) ====
004dc2ac <_ZN11BusyHandler10signalDoneEP8BusyData>:
4dc2ac: b5b0 push {r4, r5, r7, lr}
4dc2ae: 4605 mov r5, r0
4dc2b0: 480d ldr r0, [pc, #52] ; (4dc2e8 <_ZN11BusyHandler10signalDoneEP8BusyData+0x3c>)
4dc2b2: b082 sub sp, #8
4dc2b4: af00 add r7, sp, #0
4dc2b6: f107 0408 add.w r4, r7, #8
4dc2ba: 4478 add r0, pc
4dc2bc: 6078 str r0, [r7, #4]
4dc2be: f7d2 e884 blx 4ae3c8 <_ZN6QMutex4lockEv@plt>
...
Tried also on a native ARM machine, same result. I can't figure out what's happening -- is this a bug?