Page MenuHomePhabricator

[lldb] Store StackFrameRecognizers in the target instead of a global list
ClosedPublic

Authored by teemperor on Jul 14 2020, 3:07 AM.

Details

Summary

Currently the frame recognizers are stored in a global list (the list in the StackFrameRecognizersManagerImpl singleton to be precise).
All commands and plugins that modify the list are just modifying that global list of recognizers which is shared by
all Target and Debugger instances.

This is clearly against the idea of LLDB being usable as a library and it also leads to some very obscure errors as now multiple
tests are sharing the used frame recognizers. For example D83400 is currently failing as it reorders some test_ functions which
permanently changes the frame recognizers of all debuggers/targets. As all frame recognizers are also initialized in a 'once' guard,
it's also impossible to every restore back the original frame recognizers once they are deleted in a process.

This patch just moves the frame recognizers into the current target. This seems the way everyone assumes the system works
as for example the assert frame recognizers is using the current target to find the function/so-name to look for (which only
works if the recognizers are stored in the target).

Diff Detail

Event Timeline

teemperor created this revision.Jul 14 2020, 3:07 AM

The diff looks more confusing than it should be, but this essentially just does these things:

  • Deletes the StackFrameRecognizersManagerImpl singleton.
  • Deletes all the once-guards around the stack frame recognizers.
  • Makes the frame recogniers commands require a target and let them manipulate the current target's recognizer list.
  • Fixed up all the tests which either didn't have a target before they did frame recognizer changes and then of course some minor test changes for the new semantics because of the new semantics.

The change looks pretty straightforward, and having the recognizers be per target seems like a better model to me. The one difficulty with adding a target to the recognizers is that you can't add a recognizer in your .lldbinit file, since you don't have a target yet. If anybody has gotten around to doing that yet (the recognizers aren't brand new at this point) will be broken by this change.

To fix the problem for Breakpoints, I added the Dummy Target. If you add breakpoints before the debugger has any targets the breakpoint is added to the dummy target and then copied into any new targets. It might be a good thing to do that for the frame recognizers as well.

mib added a comment.Jul 14 2020, 1:04 PM

Went through the patch. Looks good to me, as long as Jim’s suggestion for dummy targets is added. Thanks for the refactoring!

MrHate added a subscriber: MrHate.Jul 15 2020, 3:34 AM
teemperor updated this revision to Diff 278143.Jul 15 2020, 4:52 AM

Sounds good to me. Reverted all the test changes too because it now mostly works as before. Also added a test for testing the new per-target behaviour.

mib accepted this revision.Jul 15 2020, 5:43 AM

Looks good to me, beside a little nit.

lldb/source/Target/Target.cpp
98

Could you use std::make_unique here ?

This revision is now accepted and ready to land.Jul 15 2020, 5:43 AM
jingham accepted this revision.Jul 15 2020, 9:55 AM

This looks good. In the breakpoint case, I added a --dummy option so that you could set breakpoints directly on the dummy target. You would do that if you were going to do something that would make new targets, and want to ensure that the breakpoints get set in all the new targets. That's probably a very little used feature, so while it would be nice to maintain consistency amongst commands that add to the dummy target, that's definitely extra-credit.

  • use make_unique

This looks good. In the breakpoint case, I added a --dummy option so that you could set breakpoints directly on the dummy target. You would do that if you were going to do something that would make new targets, and want to ensure that the breakpoints get set in all the new targets. That's probably a very little used feature, so while it would be nice to maintain consistency amongst commands that add to the dummy target, that's definitely extra-credit.

Sounds good to me, but I'll make that as its own review as that turned out to need quite a few changes.

mib accepted this revision.Jul 16 2020, 3:57 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 17 2020, 12:26 AM