Now -exec-next command uses SB API for stepping over.
Details
Diff Detail
Event Timeline
lit/tools/lldb-mi/exec/exec-next.test | ||
---|---|---|
3 | @stella.stemanova: Would be interesting to understand why (/if ?) this doesn't work on windows |
lit/tools/lldb-mi/exec/exec-next.test | ||
---|---|---|
3 | I can test it out after it's committed. |
tools/lldb-mi/MICmdCmdExec.cpp | ||
---|---|---|
382–393 | It looks like this branch is not covered by the test. Also, do we care about what happens when the client specifies an invalid thread id? |
tools/lldb-mi/MICmdCmdExec.cpp | ||
---|---|---|
384 | We can't test this branch until we have a way to get thread ID and then store it in some variable. |
lit/tools/lldb-mi/exec/exec-next.test | ||
---|---|---|
19 | 0 feels like it might actually be a valid thread id on some systems.. perhaps use really high number instead? |
lit/tools/lldb-mi/exec/exec-next.test | ||
---|---|---|
19 | I was surprised by that as well, so I tried a some experiments. I don't know how or why, but lldb-mi seems to use it's own notion of thread-ids, which are independent of os-level ids and always start with one. I guess they are just indexes into the list of threads. I don't know if that is intentional or what. | |
tools/lldb-mi/MICmdCmdExec.cpp | ||
384 | Yes, that's the issue I was alluding to. I am not going to block this patch over it or anything, but I want to make sure you are aware that you're hitting the limitations of the FileCheck test approach already. That said, if what I said above about the thread-id's always being numbered starting from one is true, then the thread ids may be predictable enough to test using -exec-next --thread 1 and avoid this problem for now. |
Changes for using thread ids in a gdb way. Also added case of specified thread into test case.
@stella.stemanova: Would be interesting to understand why (/if ?) this doesn't work on windows