[all-commits] [llvm/llvm-project] faf5f1: [dexter] Fix DexLimitSteps when breakpoint can't b...

[Orlando Cazalet-Hyams via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: faf5f1cbbac020c7a6c6de188ae96a4dc15b5cdd
      https://github.com/llvm/llvm-project/commit/faf5f1cbbac020c7a6c6de188ae96a4dc15b5cdd
  Author: OCHyams <orlando.hyams at sony.com>
  Date:   2021-03-23 (Tue, 23 Mar 2021)

  Changed paths:
    M debuginfo-tests/dexter/dex/debugger/DebuggerBase.py
    M debuginfo-tests/dexter/dex/debugger/DebuggerControllers/ConditionalController.py
    M debuginfo-tests/dexter/dex/debugger/dbgeng/dbgeng.py
    M debuginfo-tests/dexter/dex/debugger/lldb/LLDB.py
    M debuginfo-tests/dexter/dex/debugger/visualstudio/VisualStudio.py
    A debuginfo-tests/dexter/feature_tests/commands/perfect/limit_steps/limit_steps_line_mismatch.cpp

  Log Message:
  -----------
  [dexter] Fix DexLimitSteps when breakpoint can't be set at requested location

Using a DexLimitSteps command forces dexter to use the ConditionalController
debugger controller. At each breakpoint the ConditionalController needs to
understand which one has been hit. Prior to this patch, upon hitting a
breakpoint, dexter used the current source location to look up which requested
breakpoint had been hit.

A breakpoint may not get set at the exact location that the user (dexter)
requests. For example, if the requested breakpoint location doesn't exist
in the line table then then debuggers will (usually, AFAICT) set the breakpoint
at the next available valid breakpoint location.

This meant that, occasionally in unoptimised programs and frequently in
optimised programs, the ConditionalController was failing to determine which
breakpoint had been hit.

This is the fix:

Change the DebuggerBase breakpoint interface to use opaque breakpoint ids
instead of using source location to identify breakpoints, and update the
ConditionalController to track breakpoints instead of locations.

These now return a breakpoint id:

    add_breakpoint(self, file_, line)
    _add_breakpoint(self, file_, line)
    add_conditional_breakpoint(self, file_, line, condition)
    _add_conditional_breakpoint(self, file_, line, condition)

Replace:

    delete_conditional_breakpoint(self, file_, line, condition)
    _delete_conditional_breakpoint(self, file_, line, condition)

with:

    delete_breakpoint(self, id)

Add:

    get_triggered_breakpoint_ids(self)

A breakpoint id is guaranteed to be unique for each requested breakpoint, even
for duplicate breakpoint requests. Identifying breakpoints like this, instead
of by location, removes the possibility of mixing up requested and bound
breakpoints.

This closely matches the LLDB debugger interface so little work was required in
LLDB.py, but some extra bookkeeping is required in VisualStudio.py to maintain
the new breakpoint id semantics. No implementation work has been done in
dbgeng.py as DexLimitSteps doesn't seem to support dbgeng at the moment.

Testing
Added:
dexter/feature_tests/commands/perfect/limit_steps/limit_steps_line_mismatch.cpp

There were no unexpected failures running the full debuginfo-tests suite.

The regression tests use dbgeng on windows by default, and as mentioned above
dbgeng isn't supported yet, so I have also manually tested (i.e. without lit)
that this specific test works as expected with clang and Visual Studio 2017 on
Windows.

Reviewed By: TWeaver

Differential Revision: https://reviews.llvm.org/D98699