llvm-project.git/lldb/test/Shell/Target, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb][test] Fix remote Shell tests failures on Windows host (#115716) 2024-11-12T17:03:24+00:00 Vladislav Dzhidzhoev vdzhidzhoev@accesssoftek.com 2024-11-12T17:03:24+00:00 20c4e95b9c03a77c2e5ce5f354114752d380c591 Since the remote Shell test execution feature was added, these tests should now be disabled on Windows target instead of Windows host. It should fix failures on https://lab.llvm.org/staging/#/builders/197/builds/76. 
Since the remote Shell test execution feature was added, these tests
should now be disabled on Windows target instead of Windows host.

It should fix failures on
https://lab.llvm.org/staging/#/builders/197/builds/76.
 [lldb][test] Support remote run of Shell tests (#95986) 2024-10-07T18:31:33+00:00 Vladislav Dzhidzhoev vdzhidzhoev@accesssoftek.com 2024-10-07T18:31:33+00:00 32e90bbe579d39356ebd269158b1b5eef82761d4 1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT, LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake flags to pass arguments for cross-compilation and remote running of both Shell&API tests. 2. To run Shell tests remotely, it adds 'platform select' and 'platform connect' commands to %lldb substitution. 3. 'remote-linux' feature added to lit to disable tests failing with remote execution. 4. A separate working directory is assigned to each test to avoid conflicts during parallel test execution. 5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for building test sources. The recommended compiler for that is Clang. --------- Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com> 
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake
flags to pass arguments for cross-compilation and remote running of both Shell&API tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with
remote execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. The recommended compiler for that is Clang.

---------

Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
 [lldb/test] Fix target-label.test on Fuchsia 2023-06-07T00:42:09+00:00 Med Ismail Bennani ismail@bennani.ma 2023-06-07T00:40:41+00:00 bcfd85a25857294cb4a5cfa3f616f57a6911cda6 This shell test also checks some SBAPI functionalities and thus requires python support. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> 
This shell test also checks some SBAPI functionalities and thus requires
python support.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
[lldb] Disable some tests on windows 2023-06-06T23:10:05+00:00 Med Ismail Bennani ismail@bennani.ma 2023-06-06T23:05:26+00:00 431f082a55488b12ae12d4330b6c6c61dc3e61be This patch skips both `test_completion_target_create_from_root_dir` introduced in `e896612` and `target-label.test` introduced in `1e82b20` since I don't have a windows machine to try to accomodate the filesystem path style differences for these tests to pass. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> 
This patch skips both `test_completion_target_create_from_root_dir`
introduced in `e896612` and  `target-label.test` introduced in `1e82b20`
since I don't have a windows machine to try to accomodate the filesystem
path style differences for these tests to pass.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
[lldb/Target] Add ability to set a label to targets 2023-06-06T17:58:34+00:00 Med Ismail Bennani ismail@bennani.ma 2023-06-02T08:34:27+00:00 1e82b20118e31bd6c3844a84e03f701997a9b7ed This patch add the ability for the user to set a label for a target. This can be very useful when debugging targets with the same executables in the same session. Labels can be set either at the target creation in the command interpreter or at any time using the SBAPI. Target labels show up in the `target list` output, following the target index, and they also allow the user to switch targets using them. rdar://105016191 Differential Revision: https://reviews.llvm.org/D151859 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> 
This patch add the ability for the user to set a label for a target.

This can be very useful when debugging targets with the same executables
in the same session.

Labels can be set either at the target creation in the command
interpreter or at any time using the SBAPI.

Target labels show up in the `target list` output, following the target
index, and they also allow the user to switch targets using them.

rdar://105016191

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
[lldb][Windows] Always call SetExecutableModule on debugger connected 2022-09-30T10:51:56+00:00 Alvin Wong alvin@alvinhc.com 2022-09-28T09:58:51+00:00 fe17e026959cc263c12fafa3a8e9e83503f9a18b In `ProcessWindows::OnDebuggerConnected` (triggered from `CREATE_PROCESS_DEBUG_EVENT`), we should always call `Target::SetExecutableModule` regardless of whether LLDB has already preloaded the executable modules. `SetExecutableModule` has the side effect of clearing the module list of the Target, which help make sure that module #0 is the executable module and the rest of the modules are listed according to the DLL load order in the process (technically this has no real consequences but it seems to make more sense anyway.) It also fixes an issue where the modules preloaded by LLDB will be duplicated when the debuggee process actually loads the DLL. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D134636 
In `ProcessWindows::OnDebuggerConnected` (triggered from
`CREATE_PROCESS_DEBUG_EVENT`), we should always call
`Target::SetExecutableModule` regardless of whether LLDB has already
preloaded the executable modules. `SetExecutableModule` has the side
effect of clearing the module list of the Target, which help make sure
that module #0 is the executable module and the rest of the modules are
listed according to the DLL load order in the process (technically this
has no real consequences but it seems to make more sense anyway.) It
also fixes an issue where the modules preloaded by LLDB will be
duplicated when the debuggee process actually loads the DLL.

Reviewed By: labath

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