Page MenuHomePhabricator

[Target] Do not skip a stop on a breakpoint if a plan was completed
ClosedPublic

Authored by aleksandr.urakov on Oct 26 2018, 7:11 AM.

Details

Summary

This patch fixes the next situation. On Windows clang-cl makes no stub before the main function, so the main function is located exactly on module entry point. May be it is the same on other platforms. So consider the following sequence:

  • set a breakpoint on main and stop there;
  • try to evaluate expression, which requires a code execution on the debuggee side. Such an execution always returns to the module entry, and the plan waits for it there;
  • the plan understands that it is complete now and removes its breakpoint. But the breakpoint site is still there, because we also have a breakpoint on entry;
  • StopInfo analyzes a situation. It sees that we have stopped on the breakpoint site, and it sees that the breakpoint site has owners, and no one logical breakpoint is internal (because the plan is already completed and it have removed its breakpoint);
  • StopInfo thinks that it's a user breakpoint and skips it to avoid recursive computations;
  • the program continues.

So in this situation the program continues without a stop right after the expression evaluation. To avoid this I've added an additional check that the plan was completed.

The test is just the case I've caught, but it's Windows-only. It seems that the problem should exist on other platforms too, but I don't know how to test it in a cross-platform way (any tips are appreciated). The test depends on D53759.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

jingham requested changes to this revision.Oct 26 2018, 3:08 PM

This seems safe, but you certainly want to add a comment explaining why you are doing this.

We find the expression breakpoint by calling ObjectFile::GetEntryPointAddress on the main executable. So you should be able to test this everywhere by making that function result available somehow and then setting a user breakpoint there.

If you were making a dotest test I'd suggest adding SBTarget::GetEntryPointAddress and then use that.

This revision now requires changes to proceed.Oct 26 2018, 3:08 PM

Thanks! I've updated the diff according to comments.

This revision is now accepted and ready to land.Oct 29 2018, 12:15 PM
This revision was automatically updated to reflect the committed changes.