On Linux, when writing to memory, the bytes where there are breakpoints on it are left unchanged. The expected behavior is to report the newly written value -- despite the actual byte value is 0xc3. This is a LLDB internal bug so I have no way to fix it. This bug seems to be only affecting Linux, not macOS. I am yet to test it on Windows.
This causes spurious unit test failure in test_memory_read_write. Since we are writing to the code at the entry point, where there happens to be a breakpoint, the value read back is different from what we write.
I can reproduce this directly in lldb:
$ lldb '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld'
(lldb) target create "/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld"
Current executable set to '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld' (x86_64).
(lldb) b main
Breakpoint 1: where = helloworld`main, address = 0x0000000000001169
(lldb) r
Process 134979 launched: '/mnt/binja/clion/binaryninja/public/debugger/test/binaries/Linux-x86_64/helloworld' (x86_64)
Process 134979 stopped
* thread #1, name = 'helloworld', stop reason = breakpoint 1.1
frame #0: 0x0000555555555169 helloworld`main
helloworld`main:
-> 0x555555555169 <+0>: endbr64
0x55555555516d <+4>: pushq %rbp
0x55555555516e <+5>: movq %rsp, %rbp
0x555555555171 <+8>: subq $0x20, %rsp
(lldb) memory write 0x555555555169 -s 4 aaaaaaaa
(lldb) x/4xw 0x555555555169
0x555555555169: 0xaaaaaaf3 0xe5894855 0x20ec8348 0x48ec7d89
It can be seen the first four bytes become 0xaaaaaaf3 after the memory write, instead of the expected value 0xaaaaaaaa. I need to file this bug to LLDB.
On Linux, when writing to memory, the bytes where there are breakpoints on it are left unchanged. The expected behavior is to report the newly written value -- despite the actual byte value is 0xc3. This is a LLDB internal bug so I have no way to fix it. This bug seems to be only affecting Linux, not macOS. I am yet to test it on Windows.
This causes spurious unit test failure in
test_memory_read_write
. Since we are writing to the code at the entry point, where there happens to be a breakpoint, the value read back is different from what we write.I can reproduce this directly in lldb:
It can be seen the first four bytes become
0xaaaaaaf3
after the memory write, instead of the expected value0xaaaaaaaa
. I need to file this bug to LLDB.