This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Construct the dummy target when the first Dummy object is constructed
ClosedPublic

Authored by teemperor on Aug 22 2019, 3:41 AM.

Details

Summary

We should always have a dummy target, so we might as well construct it directly when we create a Debugger object.

The idea is that if this patch doesn't cause any problems that we can get rid of all the logic
that handles situations where we don't have a dummy target (as all that code is currently
untested as there seems to be no way to have no dummy target in LLDB).

Diff Detail

Repository
rL LLVM

Event Timeline

teemperor created this revision.Aug 22 2019, 3:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2019, 3:41 AM
labath accepted this revision.Aug 22 2019, 3:51 AM
labath added a reviewer: jingham.
labath added a subscriber: jingham.

This looks good to me (I wanted to do something like that myself at one point), but maybe let @jingham have a say too. (Overall, I would say that shouldn't be any reason why constructing a dummy target should ever fail, nor a reason for its creation to consume a large chunk of any kind of resource, so we can save ourselves a lot of second-guessing by just ensuring that the dummy target really always is there.)

lldb/include/lldb/Core/Debugger.h
403 ↗(On Diff #216578)

this would be m_dummy_target_sp, according to the lldb style.

This revision is now accepted and ready to land.Aug 22 2019, 3:51 AM
teemperor updated this revision to Diff 216581.Aug 22 2019, 4:07 AM
  • Fix variable name.
  • Move GetDummyTarget to header as it's only a one-liner.
jingham accepted this revision.Aug 22 2019, 10:15 AM

You can go a long time without actually using the Dummy target, which is why I made it lazily.

Thinking of lldb as the command line program, we tend to think "I'll only ever make one debugger" so making one extra per-debugger thing doesn't seem very important. But since the Debugger holds the Console, most UI's make one Debugger per debugging session, and may have many of them. So if making the one-per-debugger thing is not trivial, you do need to think a little harder about the cost.

OTOH, as Pavel says, a target with no executables that never connects to any platforms, or gets any expressions run in it, should be really cheap. So I'm fine with this change.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2019, 2:20 AM