Negative breakpoint ID’s are used for breakpoints lldb sets for internal
purposes. You can see the internal breakpoints with the “break list -i”
command.
“continue” doesn’t usually need to set internal breakpoints, however. And
we don’t usually tell you about internal breakpoint hits, especially if you
hit a user breakpoint at the same time. So that is a little curious. But
I also wonder if you are hitting this breakpoint over and over?
Hi Jim, Thanks for your reply. Yes, I have hit the breakpoint over and
over.
I replay the same debugging process again today. This time, the break point
is set as breakpoint 2 (not breakpoint 3 in my early email). When I input
"break list 2.1“, lldb shows:
(lldb) br list 2.1
2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1,
resolved = 1, hit count = 1
2.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1
When I use "continue" to let the program to go on, lld shows:
(lldb) br list 2.1
2: file = 'Executor.cpp', line = 3222, exact_match = 0, locations = 1,
resolved = 1, hit count = 1
2.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1
(lldb) n
Process 6706 stopped
* thread #1, name = 'klee', stop reason = breakpoint 2.1 -4.1
frame #0:
klee`klee::Executor::executeMemoryOperation(this=0x0000000001278800,
state=0x000000000132d710, isWrite=true, address=ref<klee::Expr> @
0x00007fffffffd480, value=ref<klee::Expr> @ 0x00007fffffffd4b0,
target=0x0000000000000000) at Executor.cpp:3228
3225 ref<Expr> value /* undef if
read */,
3226 KInstruction *target /* undef
if write */) {
3227 Expr::Width type = (isWrite ? value->getWidth() :
-> 3228 getWidthForLLVMType(target->inst->getType()));
3229 unsigned bytes = Expr::getMinBytesForWidth(type);
3230 std::string name = "node";
3231 if (SimplifySymIndices) {
(lldb)
Obviously, the program do NOT go on. As you said, internal breakpoints were
hit, because of a negative number "-4.1" in stop reason. When I input
"continue" again, it shows.
(lldb) n
Process 6706 stopped
* thread #1, name = 'klee', stop reason = breakpoint 2.1 -6.1
frame #0:
klee`klee::Executor::executeMemoryOperation(this=0x0000000001278800,
state=0x000000000132d710, isWrite=true, address=ref<klee::Expr> @
0x00007fffffffd480, value=ref<klee::Expr> @ 0x00007fffffffd4b0,
target=0x0000000000000000) at Executor.cpp:3228
3225 ref<Expr> value /* undef if
read */,
3226 KInstruction *target /* undef
if write */) {
3227 Expr::Width type = (isWrite ? value->getWidth() :
-> 3228 getWidthForLLVMType(target->inst->getType()));
3229 unsigned bytes = Expr::getMinBytesForWidth(type);
3230 std::string name = "node";
3231 if (SimplifySymIndices) {
The negative number in stop reason becomes to "-6.1". When I query internal
breakpoints with the “break list -i” command, it shows.
(lldb) break list -i
Current breakpoints:
Kind: shared-library-event
-1: address = klee[0x00000000005361a0], locations = 1 Options: disabled
one-shot
-1.1: where = klee`_start, address = 0x00000000005361a0, unresolved, hit
count = 1
Kind: shared-library-event
-2: address = ld-linux-x86-64.so.2[0x0000000000011060], locations = 1,
resolved = 1, hit count = 0
-2.1: where = ld-linux-x86-64.so.2`_dl_debug_state, address =
0x00007ffff7de8060, resolved, hit count = 0
Kind: step-out
-6: address = klee[0x0000000000547807], locations = 1, resolved = 1, hit
count = 1 Options: enabled tid: 0x1a32
-6.1: where =
klee`klee::Executor::executeMemoryOperation(klee::ExecutionState&, bool,
klee::ref<klee::Expr>, klee::ref<klee::Expr>, klee::KInstruction*) + 39 at
Executor.cpp:3228, address = 0x0000000000547807, resolved, hit count = 1
I can not understand outputs from "break list -i” command. I wonder how to
let the program to go on. BTW, I use lldb-4.0 in Ubuntu 16.04 AMD64.
-Jian