[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

David Spickett via lldb-commits lldb-commits at lists.llvm.org
Mon Aug 5 07:53:02 PDT 2024


DavidSpickett wrote:

I reduced `lldb/test/API/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py` a bit to the point where it stalls, which is when it tries to step over from breakpoint 2 to 3 in `test_step_over`:
```
    int b = func(); // breakpoint_2
    a = b + func(); // breakpoint_3
```

These are the placed breakpoints:
```
1: file = '/home/david.spickett/llvm-project/lldb/test/API/functionalities/breakpoint/step_over_breakpoint/main.cpp', line = 7, exact_match = 0
    1.1:
      module = /home/david.spickett/build-llvm-arm/lldb-test-build.noindex/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.test_step_over_dwo/a.out
      compile unit = main.cpp
      function = main
      location = /home/david.spickett/llvm-project/lldb/test/API/functionalities/breakpoint/step_over_breakpoint/main.cpp:7:9
      address = 0x0064c508
      resolved = true
      hardware = false
      hit count = 1

2: source regex = "breakpoint_2", exact_match = 0
    2.1:
      module = /home/david.spickett/build-llvm-arm/lldb-test-build.noindex/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.test_step_over_dwo/a.out
      compile unit = main.cpp
      function = main
      location = /home/david.spickett/llvm-project/lldb/test/API/functionalities/breakpoint/step_over_breakpoint/main.cpp:8:13
      address = 0x0064c510
      resolved = true
      hardware = false
      hit count = 0

Condition: false

3: source regex = "breakpoint_3", exact_match = 0
    3.1:
      module = /home/david.spickett/build-llvm-arm/lldb-test-build.noindex/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.test_step_over_dwo/a.out
      compile unit = main.cpp
      function = main
      location = /home/david.spickett/llvm-project/lldb/test/API/functionalities/breakpoint/step_over_breakpoint/main.cpp:9:9
      address = 0x0064c518
      resolved = true
      hardware = false
      hit count = 0

Condition: false
```
And where they end up in the instructions:
```
000004ec <main>:
 4ec:   e92d4800        push    {fp, lr}
 4f0:   e1a0b00d        mov     fp, sp
 4f4:   e24dd018        sub     sp, sp, #24
 4f8:   e3002000        movw    r2, #0
 4fc:   e50b2004        str     r2, [fp, #-4]
 500:   e50b0008        str     r0, [fp, #-8]
 504:   e58d100c        str     r1, [sp, #12]
 508:   e3000000        movw    r0, #0            << 1
 50c:   e58d0008        str     r0, [sp, #8]
 510:   ebfffff3        bl      4e4 <_Z4funcv>    << 2
 514:   e58d0004        str     r0, [sp, #4]
 518:   e59d0004        ldr     r0, [sp, #4]      << 3
```

If I enable the `lldb state` log I see this:
```
python3.8        Process::ResumeSynchronous -- locking run lock
b-remote.async>  (plugin = gdb-remote, state = running)
python3.8        (plugin = gdb-remote, state = running, restarted = 0)
b-remote.async>  (plugin = gdb-remote, state = stopped)
b-remote.async>  (plugin = gdb-remote, state = stopped, stop_id = 9
b-remote.async>  (plugin = gdb-remote, state = running)
b-remote.async>  (plugin = gdb-remote, state = stopped)
b-remote.async>  (plugin = gdb-remote, state = stopped, stop_id = 10
b-remote.async>  (plugin = gdb-remote, state = running)
b-remote.async>  (plugin = gdb-remote, state = stopped)
b-remote.async>  (plugin = gdb-remote, state = stopped, stop_id = 11
b-remote.async>  (plugin = gdb-remote, state = running)
b-remote.async>  (plugin = gdb-remote, state = stopped)
```
Then running/stopped/stopped repeats over and over.

`lldb process` log:
```
b-remote.async>  (plugin = gdb-remote, state = stopped)
b-remote.async>  (plugin = gdb-remote, state = stopped, stop_id = 96677
intern-state     Process::ShouldBroadcastEvent: should_resume: 1 state: stopped was_restarted: 0 report_stop_vote: -1.
intern-state     Process::ShouldBroadcastEvent (0xd86029b8) Restarting process from state: stopped
intern-state     Process::PrivateResume() m_stop_id = 96677, public state: running private state: stopped
b-remote.async>  (plugin = gdb-remote, state = running)
intern-state     Process thinks the process has resumed.
intern-state     Process::ShouldBroadcastEvent (0xd86029b8) => new state: stopped, last broadcast state: running - NO
intern-state     Process::HandlePrivateEvent (pid = 3526293) suppressing state stopped (old state running): should_broadcast == false
intern-state     timeout = <infinite>, event_sp)...
intern-state     Process::ShouldBroadcastEvent (0xd8601030) => new state: running, last broadcast state: running - NO
intern-state     Process::HandlePrivateEvent (pid = 3526293) suppressing state running (old state running): should_broadcast == false
intern-state     timeout = <infinite>, event_sp)...
b-remote.async>  (plugin = gdb-remote, state = stopped)
b-remote.async>  (plugin = gdb-remote, state = stopped, stop_id = 96678
```
Again, repeats.

Tell me if there's anything more interesting to look at.

> My question basically was: what is the stop-reply packet for a single step (vCont:s) operation on arm32?

```
b-remote.async>  <  26> send packet: $vCont;s:p365766.365766#12
b-remote.async>  < 293> read packet: $T05thread:p365766.365766;name:test.o;threads:365766;thread-pcs:004004ea;00:01000000;01:84f4feff;02:8cf4feff;03:01000000;04:40f3feff;05:00000000;06:00000000;07:20f3feff;08:00000000;09:00000000;0a:c80f4100;0b:00000000;0c:a8f3feff;0d:20f3feff;0e:a5d5edf7;0f:ea044000;10:30008e00;reason:trace;#61
```

https://github.com/llvm/llvm-project/pull/96260


More information about the lldb-commits mailing list