llvm-project.git/lldb/test/API/functionalities/thread/create_after_attach, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb] Move lldb_enable_attach from test_common to a separate header (#139550) 2025-05-13T15:52:23+00:00 Pavel Labath pavel@labath.sk 2025-05-13T15:52:23+00:00 91ea49499325aeff8426135721b1bd432e5b7780 test_common is force-included into every compilation, which causes problems when we're compiling assembly code, as we were in #138805. This avoids that as we can include the header only when it's needed. 
test_common is force-included into every compilation, which causes
problems when we're compiling assembly code, as we were in #138805.

This avoids that as we can include the header only when it's needed.
 [NFC][Py Reformat] Reformat python files in lldb 2023-05-25T19:54:09+00:00 Jonas Devlieghere jonas@devlieghere.com 2023-05-25T15:48:57+00:00 2238dcc39358353cac21df75c3c3286ab20b8f53 This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460
[lldb][tests] Automatically call compute_mydir (NFC) 2022-06-17T21:34:49+00:00 Dave Lee davelee.com@gmail.com 2022-06-17T00:38:47+00:00 4cc8f2a017c76af25234afc7c380550e9c93135c Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077 
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077
[lldb] Remove lldbtest.getBuildFlags 2021-12-30T11:19:24+00:00 Pavel Labath pavel@labath.sk 2021-12-30T10:22:26+00:00 d7dbe2c4a00ba2abd998328ad6b8023637bc71d9 It was being used only in some very old tests (which pass even without it) and its implementation is highly questionable. These days we have different mechanisms for requesting a build with a particular kind of c++ library (USE_LIB(STD)CPP in the makefile). 
It was being used only in some very old tests (which pass even without
it) and its implementation is highly questionable.

These days we have different mechanisms for requesting a build with a
particular kind of c++ library (USE_LIB(STD)CPP in the makefile).
[lldb] [test] Workaround symlink-related test failures 2021-03-01T15:23:36+00:00 Michał Górny mgorny@moritz.systems 2021-02-22T22:39:39+00:00 15f067f1c79fac34910eaf50f612854eb1d58bb5 Use realpath() when spawning the executable create_after_attach to workaround a FreeBSD plugin (and possibly others) problem. If the executable is started via a path containing a symlink, it is added to the module list twice -- via the real and apparent path. This in turn cases the requested breakpoint to resolve twice. Use realpath() for main program path in lldb-vscode breakpoint tests to workaround a similar problem. If the passed path does not match the realpath, lldb-vscode does not report the breakpoints as verified and causes tests to fail. Since the underlying problems are non-trivial to fix and the purpose of these tests is not to reproduce symlink problems, let's apply trivial workarounds to make them pass. Differential Revision: https://reviews.llvm.org/D97230 
Use realpath() when spawning the executable create_after_attach
to workaround a FreeBSD plugin (and possibly others) problem.
If the executable is started via a path containing a symlink, it is
added to the module list twice -- via the real and apparent path.
This in turn cases the requested breakpoint to resolve twice.

Use realpath() for main program path in lldb-vscode breakpoint tests
to workaround a similar problem.  If the passed path does not match
the realpath, lldb-vscode does not report the breakpoints as verified
and causes tests to fail.

Since the underlying problems are non-trivial to fix and the purpose
of these tests is not to reproduce symlink problems, let's apply
trivial workarounds to make them pass.

Differential Revision: https://reviews.llvm.org/D97230
[lldb] Convert more assertTrue to assertEqual (NFC) 2021-02-04T05:15:08+00:00 Dave Lee davelee.com@gmail.com 2021-02-02T22:46:37+00:00 0ed758b26041ef4ec57e8511d289fb0b84468775 Follow up to D95813, this converts multiline assertTrue to assertEqual. Differential Revision: https://reviews.llvm.org/D95899 
Follow up to D95813, this converts multiline assertTrue to assertEqual.

Differential Revision: https://reviews.llvm.org/D95899
[lldb] [test] Link FreeBSD test failures to bugs 2020-12-07T08:56:50+00:00 Michał Górny mgorny@moritz.systems 2020-11-27T13:10:10+00:00 266c90fec899356aa2c88f1e614d40d554db6fb3 Differential Revision: https://reviews.llvm.org/D92740 
Differential Revision: https://reviews.llvm.org/D92740
[lldb] Enable FreeBSDRemote plugin by default and update test status 2020-11-05T16:49:46+00:00 Michał Górny mgorny@moritz.systems 2020-11-04T09:16:30+00:00 2c2eb5e6702bf3bbb8fb8f09790b1ab7b139e879 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 
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/Test] Remove support for forking a subprocess from the test suite. 2020-07-15T15:57:54+00:00 Jonas Devlieghere jonas@devlieghere.com 2020-07-15T15:51:24+00:00 700dd17399bdcf2c580121e52b20e5768663dfe5 Remove the forkSubprocess method and its bookkeeping. TestCreateAfterAttach is the only test using the fork method and I'm not convinced it adds enough to warrant the maintenance. Pavel suggested the same thing in D83815. 
Remove the forkSubprocess method and its bookkeeping.
TestCreateAfterAttach is the only test using the fork method and I'm not
convinced it adds enough to warrant the maintenance. Pavel suggested the
same thing in D83815.
[lldb/Test] Always set the cleanupSubprocesses tear down hook 2020-07-14T21:05:56+00:00 Jonas Devlieghere jonas@devlieghere.com 2020-07-14T19:12:05+00:00 4aafc479f28ce1ad952f66ac3758f69060c77a08 Always clean up subprocesses on tear down instead of relying on the caller to do so. This is not only less error prone but also means the tests can be more concise. Differential revision: https://reviews.llvm.org/D83787 
Always clean up subprocesses on tear down instead of relying on the
caller to do so. This is not only less error prone but also means the
tests can be more concise.

Differential revision: https://reviews.llvm.org/D83787