[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