LLDB Show trap opcodes in memory dump

I'm wondering if it is possible with LLDB's memory dumper to see trap opcodes in locations where I've just set a beakpoint? As I see LLDB is smart enough to shadow trap opcodes with original ones:

(lldb) memory read --format instruction --count 5 0x00000076619b5478
->  0x76619b5478: 0xf9401668   ldr    x8, [x19, #0x28]
    0x76619b547c: 0xf9400289   ldr    x9, [x20]
    0x76619b5480: 0xeb09011f   cmp    x8, x9
    0x76619b5484: 0x540000e1   b.ne   0x76619b54a0              ; <+200>
    0x76619b5488: 0xa95d7bf3   ldp    x19, x30, [sp, #0x1d0]
(lldb) breakpoint set --address 0x76619b5488
Breakpoint 3: where = libface_detector_v2_jni.so`___lldb_unnamed_symbol20247$$libface_detector_v2_jni.so + 176, address = 0x00000076619b5488
(lldb) memory read --format instruction --count 5 0x00000076619b5478
->  0x76619b5478: 0xf9401668   ldr    x8, [x19, #0x28]
    0x76619b547c: 0xf9400289   ldr    x9, [x20]
    0x76619b5480: 0xeb09011f   cmp    x8, x9
    0x76619b5484: 0x540000e1   b.ne   0x76619b54a0              ; <+200>
    0x76619b5488: 0xa95d7bf3   ldp    x19, x30, [sp, #0x1d0]

Here I set a break at 0x76619b5488 but dumper still shows original instruction at that place. help memory read has no hints about how one could see trap opcodes.

Any ideas?

P.S. It is an LLDB bundled with Android SDK, claimed version: 7.0.0. Target is an Android Aarch64.

Solution

Here I set a break at 0x76619b5488 but dumper still shows original instruction at that place.

This is very typical of debuggers: they don't want to confuse you with the breakpoint instructions they inserted, and so show you the original contents of memory.

On x86, doing anything else would de-sync the instruction stream (because instructions are variable length), so showing the actual instructions with breakpoints inserted would produce utter garbage.

how one could see trap opcodes

You could copy (take a snapshot of) a memory region (e.g. 1 function's worth of memory) and compare it with current contents while there is a breakpoint on that function. They will not match. This is one of the ways a program can detect that it is being debugged.

You can then ask LLDB to disassemble the copied region (for the copy taken after breakpoint insertion), and you will see the breakpoint you wish to observe (but IP-relative offsets will be pointing to wrong locations).

I don't know of a simpler way to achieve that.