Commit 7deb970ef added REQUIRES and UNSUPPORTED lines to a test which is
sensitive to line number changes. Update the line number reference in the test.

As this is a test that actually gets to operating the debugger, it
needs to be limited to scenarios where the debugger is available.

(We'll file this in the set of things Dexter doesn't handle gracefully..)

Add optional keyword argument 'on_line' to DexLabel to label the specifed line
instead of the line the command is found on.

This will be helpful when used alongside DexDeclareFile (D99651).

Reviewed By: TWeaver

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

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

The test optnone-simple-functions.cpp added in D97668 fails on macOS.
os.path.exists raises an exception because we pass it None. Guard against this.

Related revision: https://reviews.llvm.org/D97668

Reviewed By: mehdi_amini

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

Add dexter tests using the optnone attribute in various scenarios. Our users
have found optnone useful when debugging optimised code. We have these tests
downstream (and one upstream already: D89873) and we would like to contribute
them if there is any interest.

The tests are fairly self explanatory. Testing optnone with:
  * optnone-fastmath.cpp: floats and -ffast-math,
  * optnone-simple-functions: simple functions and integer arithmetic,
  * optnone-struct-and-methods: a struct with methods,
  * optnone-vectors-and-functions: templates and integer vector arithmetic.

optnone-vectors-and-functions contains two FIXMEs. The first problem is that
lldb seems to struggle with evaluating expressions with the templates used
here (example below). Perhaps this is PR42920?

  (lldb) p TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
  error: <user expression 0>:1:1: no template named 'TypeTraits'
  TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
  ^
The second is that while lldb cannot evaluate the following expression, gdb
can, but it reports that the variable has been optimzed away. It does this when
compiling at O0 too. llvm-dwarfdump shows that MysteryNumber does have a
location. I don't know whether the DIE is bad or if both debuggers just don't
support it.

  TypeTraits<int __attribute__((ext_vector_type(4)))>::MysteryNumber

  DW_TAG_variable
      DW_AT_specification   (0x0000006b "MysteryNumber")
      DW_AT_location        (DW_OP_addr 0x601028)
      DW_AT_linkage_name    ("_ZN10TypeTraitsIDv4_iE13MysteryNumberE")

Reviewed By: rnk

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

Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.

Reviewed By: JDevlieghere, MaskRay

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

If the default target and host triple don't match then print the following
message when the lit test runs:

    Forcing dexter tests to use host triple {HOST_TRIPLE}.

If we can't target the host arch then, when lit runs, we mark
the dexter test directories as UNSUPPORTED and print the message:

    Host triple {HOST_TRIPLE} not supported. Skipping dexter tests in
    the debuginfo-tests project.

Reviewed By: rnk

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