software breakpoints show up in a memory read when debugging via rsp

Expected behavior when doing a memory read or disassembly is that software breakpoints don’t show up – the original code does.

Using lldb on x86 Linux, I run a test program and set a breakpoint, then disassemble. I get this:

Process 22519 stopped

  • thread #1: tid = 22519, 0x00000000004004db test`main(argc=1, argv=0x00007fffffffea58) + 11 at test.c:3, name = ‘test’, stop reason = breakpoint 1.1

frame #0: 0x00000000004004db test`main(argc=1, argv=0x00007fffffffea58) + 11 at test.c:3

1 int main (int argc, void **argv)

2 {

→ 3 int i = 1;

4 int j = 2;

5 int k = 3;

6 return 0;

7 }

(lldb) dis


0x4004d0 <+0>: pushq %rbp

0x4004d1 <+1>: movq %rsp, %rbp

0x4004d4 <+4>: movl %edi, -0x14(%rbp)

0x4004d7 <+7>: movq %rsi, -0x20(%rbp)

→ 0x4004db <+11>: int3

0x4004dc <+12>: hlt

0x4004de <+14>: addl %eax, (%rax)

0x4004e0 <+16>: addb %al, (%rax)

Shouldn’t the remote gdbserver (lldb-server, in this case) replace the software breakpoint instructions with the actual opcodes?

Hi Ted,

Thanks for the bugreport.

You are correct, they should be removed. There is a test that was added specifically to track this.


Yes, if you set breakpoints via the z packets, then the GDB server should remove any breakpoint traps from any memory that is read via the memory read/write packets (m/M and x/X packets (binary memory read)).