This is an archive of the discontinued LLVM Phabricator instance.

Add a repeat command option for "thread backtrace --count N".
ClosedPublic

Authored by jingham on Feb 4 2022, 4:29 PM.

Details

Summary

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack 10 frames at a time.
Previously the repeat just redid the previous command. "thread backtrace" without a
--count will continue to just dump the complete stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

Diff Detail

Event Timeline

jingham requested review of this revision.Feb 4 2022, 4:29 PM
jingham created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 4:29 PM

API and code change make sense, but I think we should be able to simplify the test.

lldb/test/API/commands/thread/backtrace/TestThreadBacktraceRepeat.py
19–29

I assume you copied this from an existing tests. Can we make the test simpler (by not having two threads) and therefore not having to skip it in so many configurations?

jingham added inline comments.Feb 7 2022, 4:03 PM
lldb/test/API/commands/thread/backtrace/TestThreadBacktraceRepeat.py
19–29

No. One of the things I want to test is that the repeat command sticks to backtracking the thread that you started on, which I can only test with more than one thread. I also need to test that when you list TWO threads, the repeat command continues listing both threads, rather than arbitrarily picking one. Again for that purpose I need two threads. I could make two tests one with one thread and one with two, but that seems a bit silly.

BTW, the test I copied this from tries to do some "step out's" after stopping where this test stops. I don't know (yet) whether the expected failures are in the initial rendezvous or in the stepping. I'll only be able to figure that out once the test is running on those systems... For instance, I bet this won't fail on FreeBSD because I don't run the process to exit, I just kill it at the breakpoint.

jingham updated this revision to Diff 407023.Feb 8 2022, 6:09 PM

Ran clang-format over the diff

Added a simpler test that doesn't try to rendezvous the two threads so they are in known states, but just does a repeated backtrace on the first thread that hits the breakpoint. Hopefully the simpler test will run on more platforms.

JDevlieghere accepted this revision.Feb 8 2022, 8:21 PM

Thanks Jim. LGTM.

This revision is now accepted and ready to land.Feb 8 2022, 8:21 PM
labath added a subscriber: labath.Feb 15 2022, 12:02 AM

I've fixed the synchronization code in f8d42c55ec6e9. Based on my experiments, lldb reports still reports a stop reason for suspended threads (regardless of the platform), so the code should expect continue_to_breakpoint to return two threads when it is synchronizing them.