llvm-project.git/lldb/test/Shell/Recognizer/assert.test, branch main

When the Debugger runs HandleProcessEvent it should allow

2023-05-10T22:40:40+00:00

selecting the "Most relevant" frame.

If you don't do that, then the correct frame gets selected, but it
happens AFTER the frame info gets printed in the stop message, so
you don't see the selected frame.

The test for this hid the issue because it ran `frame info` and
checked the result of that.  That happens after the recognizer selects
the frame, and so it was right.  But if the recognizer is working
correctly it will have already done the same printing in the stop
message, and this way we also verify that the stop message was right.

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

[lldb] Remove redundant XFAIL

2022-12-12T16:05:03+00:00

The test is `UNSUPPORTED: system-linux` so the XFAIL for linux is
redundant.

Part of the project to eliminate special handling for triples in lit
expressions.

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

[lldb] Skip Recognizer/assert.test on linux

2022-06-21T14:51:02+00:00

-> PR56144

[lldb] [test] Update test status for NetBSD

2020-12-20T10:32:43+00:00

[lldb] Enable FreeBSDRemote plugin by default and update test status

2020-11-05T16:49:46+00:00

The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets.  Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.

Revisit the method of switching plugins.  Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.

Update the test status.  Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure.  For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.

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

[LLDB] Fix typo in xfail decorator assert.test

2020-05-13T03:53:56+00:00

Fix a typo in earlier xfailed assert.test replace // with #.

[LLDB] Mark some xfails for arm-linux

2020-05-13T03:05:27+00:00

This patch marks following tests as xfail for arm-linux target.

lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/Shell/Recognizer/assert.test

Bugs have been filed for all of them for the corresponding failing
component.

[lldb/test] Add alternate symbol to StackFrame Recognizer

2020-02-11T10:44:37+00:00

This reimplements commit 6b2979c12300b90a1e69791d43ee9cff14f4265e and updates
the tests to reflect the addition of the alternate symbol attribute.

Signed-off-by: Med Ismail Bennani

Revert "[lldb] Fix+re-enable Assert StackFrame Recognizer on Linux"

2020-02-10T21:27:35+00:00

This reverts commit 1a39f1b966a8d8f15ed0d5a832d5097cccefe93b as
it breaks macOS.

[lldb] Fix+re-enable Assert StackFrame Recognizer on Linux

2020-02-10T09:29:32+00:00

D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.

I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.

DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.

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