This is an archive of the discontinued LLVM Phabricator instance.

Add -b (--continue-to-breakpoint) option to the "process continue" command
ClosedPublic

Authored by jingham on May 26 2022, 6:37 PM.

Details

Summary

Sometimes you have a complex set of breakpoints, some enabled and some not, but for the next continue you just want to run till you hit some subset of the breakpoints you have set without disturbing the state of other breakpoints. This patch adds an option for that. Just say:

(lldb) continue -b 10

That will temporarily disable all the other breakpoints but 10, run till you hit 10, and then stop.

Note, this is just a continue option, not a thread plan, so if you stop for any other reason like a signal, or you interrupt the process, then the state will be restored and you will stop. We don't force continuing to one of the breakpoints specified. continue is not stateful, so I think this is what people would expect.

You can also specify a breakpoint name, and the option can be repeated, so:

(lldb) continue -b 10 -b MyBKPTS -b 20

will continue till you hit either breakpoints 10, 20, or any that have the name MyBKTPS.

Continuing to a breakpoint that's disabled is not going to be very satisfying. I could either temporarily enable the breakpoint, continue to it, then disable it again, or return an error. In this patch I return an error, since I think you would want to know you are trying to continue to a breakpoint you've disabled. But I could be persuaded the other behavior is more convenient.

BTW, this is a built-in version of the Python command in:

https://reviews.llvm.org/D125148

I still think that's worthwhile as an example, but the behavior seemed useful enough to be built-in.

Diff Detail

Event Timeline

jingham created this revision.May 26 2022, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 26 2022, 6:37 PM
jingham requested review of this revision.May 26 2022, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 26 2022, 6:37 PM

I noticed that the example python command and this feature don't support specifying breakpoint locations. Should it?

kastiglione added inline comments.Jun 1 2022, 11:14 AM
lldb/source/Commands/CommandObjectProcess.cpp
740

this should be old_sync (no !)

jingham updated this revision to Diff 435013.Jun 7 2022, 6:06 PM

Allow for specifying breakpoint locations as well as breakpoints.
Also fix the sync setting & resetting.

jingham marked an inline comment as done.Jun 7 2022, 6:08 PM

I noticed that the example python command and this feature don't support specifying breakpoint locations. Should it?

Man, that was WAY harder...

lldb/source/Commands/CommandObjectProcess.cpp
740

Yup. The scope exit was overkill anyway. I fixed this and also added to the test to make sure it gets set back correctly.

jingham marked an inline comment as done.Jun 7 2022, 6:08 PM

Added the ability to specify breakpoint locations to run to as well as breakpoints and breakpoint names.

I have to fix the doc string for the -b option since it's now a bkpt_id_list. But that won't affect the logic so I'll do that and update the patch tomorrow.

jingham updated this revision to Diff 435248.Jun 8 2022, 10:44 AM

Fixed the option definition to specify this is a bkpt_id_list not a breakpoint id (since that's what it is now that we're using the breakpoint id list parser), and removed the verbiage that that made redundant.

Added one hopefully helpful comment.

kastiglione accepted this revision.Jun 21 2022, 4:30 PM

thanks Jim

lldb/source/Commands/CommandObjectProcess.cpp
600

from a quick read, it looks like this step will silently ignore bkpts it can't disable.

then a couple lines down the user might be told the breakpoints don't actually exist, which may not be true?

636–637

this logic looks off, why is any_enabled set to true when the loc_id is LLDB_INVALID_BREAK_ID?

lldb/test/API/commands/process/continue_to_bkpt/TestContinueToBkpts.py
3

s/-t/-b/

17

if you edit this file before committing, you can remove this line. mydir is now automatically computed.

This revision is now accepted and ready to land.Jun 21 2022, 4:30 PM
jingham updated this revision to Diff 438879.Jun 21 2022, 5:40 PM

Address review comments

This revision was landed with ongoing or failed builds.Jun 22 2022, 9:55 AM
This revision was automatically updated to reflect the committed changes.

This just broke trunk. Look at this repro:

#include <chrono>
#include <thread>

void f3() {
  int m;
  m = 2; // thread 3 - line 6
}

void f2() {
  int n;
  n = 1; // thread 2 - line 11
  std::thread t3(f3);
  t3.join();
}

int main() { // main
  std::thread t2(f2);
  t2.join();
  return 0;
}

b main
b 6
b 11
r # stopped at main
c # stopped at 11
c # doesn't stop at 6! It goes to the end of the program

I think this might have broken a bunch of testcases on the lldb-x64-windows-ninja buildbot too, e.g. https://lab.llvm.org/buildbot/#/builders/83/builds/20304 (CC @stella.stamenova)

cmtice added a subscriber: cmtice.Jun 23 2022, 3:58 PM

This appears to have broken a lot of LLDB tests in our bootstrap as well. Is there any chance this might get reverted?

Ignore my revert request; Your later commit seems to have fixed most of my issues.