Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
5b4100cc |
| 10-Sep-2024 |
John Harrison <harjohn@google.com> |
[lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)
Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.
[lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)
Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.
Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.
Adding unit tests for exception handling and stack trace supporting.
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2 |
|
#
3e593b9b |
| 26-Jul-2024 |
Kendal Harland <3987220+kendalharland@users.noreply.github.com> |
[lldb] Remove python helper getCompilerBinary() (#100660)
This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
uncondi
[lldb] Remove python helper getCompilerBinary() (#100660)
This causes a number of tests be `UNRESOLVED` on Windows if
`getCompiler()` has a space in the name, because `getCompilerBinary()`
unconditionally splits on whitespace and returns the first result, which
might just be`"C:\Program"` if using a compiler such as `clang-cl` `cl`
from the absolute path to Visual studio's installation directory.
Co-authored-by: kendal <kendal@thebrowser.company>
show more ...
|
Revision tags: llvmorg-19.1.0-rc1 |
|
#
ca102b21 |
| 23-Jul-2024 |
Andrew Rogers <andrurogerz@gmail.com> |
lldb: android: fix missing Python import of urlparse in lldb test utilities (#99934)
## Issue
Attempting to run the lldb API tests against a remote-android target
fails with the error `NameError:
lldb: android: fix missing Python import of urlparse in lldb test utilities (#99934)
## Issue
Attempting to run the lldb API tests against a remote-android target
fails with the error `NameError: name 'urlparse' is not defined`.
## Root Cause
It looks the Python import of `urlparse` was removed by mistake in
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when
running the lldb API tests against a remote-android target so it went
unnoticed.
## Fix
This change simply puts back the missing import. It is a one line
change.
fixes #99931
## Validation
Tested on Fedora 39 with an attached Android device:
`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb'
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver
--platform-name=remote-android
--platform-working-dir=/data/local/tmp/ds2
--platform-url=connect://localhost:5432 --compiler
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`
show more ...
|
Revision tags: llvmorg-20-init |
|
#
cbd25594 |
| 18-Jul-2024 |
dlav-sc <daniil.avdeev@syntacore.com> |
[lldb] add RISCV target specific info in API tests (#99039)
Add information about RISCV first register in python API testsuite, that
is used to check register readability in tests.
Fixed tests o
[lldb] add RISCV target specific info in API tests (#99039)
Add information about RISCV first register in python API testsuite, that
is used to check register readability in tests.
Fixed tests on RISCV target:
TestBreakpointByFileColonLine.BreakpointByLineAndColumnTestCase
TestAddressBreakpoints.AddressBreakpointTestCase
TestBreakpointAutoContinue.BreakpointAutoContinue
TestInterruptBacktrace.TestInterruptingBacktrace
TestBadAddressBreakpoints.BadAddressBreakpointTestCase
TestScriptedResolver.TestScriptedResolver
TestStopHookScripted.TestStopHooks
TestBreakpointConditions.BreakpointConditionsTestCase
TestLocalVariables.LocalVariablesTestCase
TestFindLineEntry.FindLineEntry
TestScriptedResolver.TestScriptedResolver
TestInlineSourceFiles.InlineSourceFilesTestCase
TestModuleAndSection.ModuleAndSectionAPIsTestCase
TestFrameVar.TestFrameVar
TestInferiorAssert.AssertingInferiorTestCase
TestInferiorCrashing.CrashingInferiorTestCase
TestInferiorCrashingStep.CrashingInferiorStepTestCase
TestRegistersIterator.RegistersIteratorTestCase
TestCoroutineHandle.TestCoroutineHandle
TestWithLimitDebugInfo.TestWithLimitDebugInfo
TestLLDBIterator.LLDBIteratorTestCase
TestMemoryWrite.MemoryWriteTestCase
TestNestedTemplate.NestedTemplateTestCase
TestParrayVrsCharArrayChild.TestParrayVrsCharArrayChild
TestRecursiveInferior.CrashingRecursiveInferiorTestCase
TestRecursiveInferiorStep.CrashingRecursiveInferiorStepTestCase
TestRunLocker.TestRunLocker
TestSampleTest.RenameThisSampleTestTestCase
TestUniqueTypes3.UniqueTypesTestCase3
TestPrintStackTraces.ThreadsStackTracesTestCase
TestUnicodeSymbols.TestUnicodeSymbols
TestUnusedInlinedParameters.TestUnusedInlinedParameters
TestValueVarUpdate.ValueVarUpdateTestCase
TestPtrRef2Typedef.PtrRef2TypedefTestCase
TestDataFormatterStdIterator.StdIteratorDataFormatterTestCase
TestDataFormatterStdString.StdStringDataFormatterTestCase
TestDataFormatterStdVBool.StdVBoolDataFormatterTestCase
show more ...
|
#
7021e44b |
| 09-Jul-2024 |
Vladislav Dzhidzhoev <vdzhidzhoev@accesssoftek.com> |
[lldb][test] Set target and host OS for API tests in case of remote testing
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
This comm
[lldb][test] Set target and host OS for API tests in case of remote testing
Makefile.rules uses HOST_OS and OS variables for determining host and target
OSes for API tests compilation.
This commit moves the platform detection logic from Makefile to Python lldb
test suite.
This is useful for the case of Windows-to-Linux cross-testing.
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
22ea97d7 |
| 13-Jun-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Use packaging module instead of pkg_resources (#93712)
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently swi
[lldb] Use packaging module instead of pkg_resources (#93712)
Use the packaging [1] module for parsing version numbers, instead of
pkg_resources which is distributed with setuptools. I recently switched
over to using the latter, knowing it was deprecated (in favor of the
packaging module) because it comes with Python out of the box. Newer
versions of setuptools have removed `pkg_resources` so we have to use
packaging.
[1] https://pypi.org/project/packaging/
show more ...
|
Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
d93a1260 |
| 07-Mar-2024 |
Alex Langford <alangford@apple.com> |
[lldb] Add ability to detect darwin host linker version to xfail tests (#83941)
When Apple released its new linker, it had a subtle bug that caused
LLDB's TLS tests to fail. Unfortunately this mean
[lldb] Add ability to detect darwin host linker version to xfail tests (#83941)
When Apple released its new linker, it had a subtle bug that caused
LLDB's TLS tests to fail. Unfortunately this means that TLS tests are
not going to work on machines that have affected versions of the linker,
so we should annotate the tests so that they only work when we are
confident the linker has the required fix.
I'm not completely satisfied with this implementation. That being said,
I believe that adding suport for linker versions in general is a
non-trivial change that would require far more thought. There are a few
challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but
there's no way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many
platforms have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We
do this for Windows tests (where we use LLD no matter what).
Given that this is affecting the tests on our CI, I think this is an
acceptable solution in the interim.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
#
0c02329f |
| 19-Feb-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Migrate distutils.version.LooseVersion to packaging (#82066)
The distutils package has been deprecated and was removed from Python 3.12. The migration page [1] advises to use the packaging mo
[lldb] Migrate distutils.version.LooseVersion to packaging (#82066)
The distutils package has been deprecated and was removed from Python 3.12. The migration page [1] advises to use the packaging module instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
show more ...
|
#
71e06231 |
| 20-Feb-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
Revert "[lldb] Migrate distutils.version.LooseVersion to packaging" (#82297)
Reverts llvm/llvm-project#82066 because the following tests started
failing after:
[lldb-api.commands/expression/im
Revert "[lldb] Migrate distutils.version.LooseVersion to packaging" (#82297)
Reverts llvm/llvm-project#82066 because the following tests started
failing after:
[lldb-api.commands/expression/import-std-module/deque-basic.TestDequeFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_deque-basic/TestDequeFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/deque-dbg-info-content.TestDbgInfoContentDequeFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/forward_list.TestForwardListFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_forward_list/TestForwardListFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/forward_list-dbg-info-content.TestDbgInfoContentForwardListFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_forward_list-dbg-info-content/TestDbgInfoContentForwardListFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/list.TestListFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_list/TestListFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/non-module-type-separation.TestNonModuleTypeSeparation.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_non-module-type-separation/TestNonModuleTypeSeparation_py/)
[lldb-api.commands/expression/import-std-module/queue.TestQueueFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_queue/TestQueueFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/retry-with-std-module.TestRetryWithStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_retry-with-std-module/TestRetryWithStdModule_py/)
[lldb-api.commands/expression/import-std-module/unique_ptr.TestUniquePtrFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_unique_ptr/TestUniquePtrFromStdModule_py/)
[lldb-api.commands/expression/import-std-module/unique_ptr-dbg-info-content.TestUniquePtrDbgInfoContent.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_unique_ptr-dbg-info-content/TestUniquePtrDbgInfoContent_py/)
[lldb-api.commands/expression/import-std-module/vector-of-vectors.TestVectorOfVectorsFromStdModule.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/commands_expression_import-std-module_vector-of-vectors/TestVectorOfVectorsFromStdModule_py/)
[lldb-api.functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr.TestDataFormatterLibcxxSharedPtr.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/functionalities_data-formatter_data-formatter-stl_libcxx_shared_ptr/TestDataFormatterLibcxxSharedPtr_py/)
[lldb-api.functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr.TestDataFormatterLibcxxUniquePtr.py](https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/66513/testReport/junit/lldb-api/functionalities_data-formatter_data-formatter-stl_libcxx_unique_ptr/TestDataFormatterLibcxxUniquePtr_py/)
show more ...
|
#
13dce358 |
| 19-Feb-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Migrate distutils.version.LooseVersion to packaging (#82066)
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging m
[lldb] Migrate distutils.version.LooseVersion to packaging (#82066)
The distutils package has been deprecated and was removed from Python
3.12. The migration page [1] advises to use the packaging module
instead. Since Python 3.6 that's vendored into pkg_resources.
[1] https://peps.python.org/pep-0632/#migration-advice
show more ...
|
Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
25ea0e9d |
| 01-Dec-2023 |
Brad Smith <brad@comstyle.com> |
[lldb] Make use of LD_LIBRARY_PATH on OpenBSD (#74017)
|
#
81cd283f |
| 01-Dec-2023 |
Brad Smith <brad@comstyle.com> |
[lldb/test] Add OpenBSD to _get_platform_os (#74036)
|
Revision tags: llvmorg-17.0.6 |
|
#
212a60ec |
| 16-Nov-2023 |
Jordan Rupprecht <rupprecht@google.com> |
[lldb][test] Remove `self` references from decorators (#72416)
This is partial step toward removing the vendored `unittest2` dep in favor of the `unittest` library in standard python. One of the lar
[lldb][test] Remove `self` references from decorators (#72416)
This is partial step toward removing the vendored `unittest2` dep in favor of the `unittest` library in standard python. One of the large differences is when xfail decorators are evaluated. With the `unittest2` vendored dep, this can happen at the moment of calling the test case, and with LLDB's decorator wrappers, we are passed the test class in the decorator arg. With the `unittest` framework, this is determined much earlier; we cannot decide when the test is about to start that we need to xfail.
Fortunately, almost none of these checks require any state that can't be determined statically. For this patch, I moved the impl for all the checks to `lldbplatformutil` and pointed the decorators to that, removing as many `self` (i.e. test class object) references as possible. I left wrappers within `TestBase` that forward to `lldbplatformutil` for convenience, but we should probably remove those later.
The remaining check that can't be moved statically is the check for the debug info type (e.g. to xfail only for dwarf). Fixing that requires a different approach, so I will postpone that to the next patch.
show more ...
|
Revision tags: llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
#
e634c2f7 |
| 11-Aug-2023 |
Alex Langford <alangford@apple.com> |
[lldb] Remove use of __future__ in python
These were useful primarily for the Python 2 to 3 transition. Python 2 is no longer supported so these are no longer necessary.
Differential Revision: http
[lldb] Remove use of __future__ in python
These were useful primarily for the Python 2 to 3 transition. Python 2 is no longer supported so these are no longer necessary.
Differential Revision: https://reviews.llvm.org/D157759
show more ...
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
2238dcc3 |
| 25-May-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[NFC][Py Reformat] Reformat python files in lldb
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 problem
[NFC][Py Reformat] Reformat python files in lldb
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
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6 |
|
#
6335deb6 |
| 21-Nov-2022 |
Pavel Labath <pavel@labath.sk> |
[lldb/test] Use SBPlatform info for lldbplatformutil.getPlatform()
Previously, we just used the platform name. This worked mostly OK, but it required adding special handling for any unusual (and pot
[lldb/test] Use SBPlatform info for lldbplatformutil.getPlatform()
Previously, we just used the platform name. This worked mostly OK, but it required adding special handling for any unusual (and potentially downstream) platform plugins, as evidenced by the hardcoding of the qemu-user platform.
The current implementation was added in D121605/21c5bb0a636c23ec75b13681c0a6fdb03ecd9c0d, which this essentially reverts and goes back to the previous method of retrieving the platform name from the platform triple (the "OS" field).
The motivation for D121605 was the ability to retrieve the process without constructing an SBDebugger object (which would be necessary in a world where SBPlatforms are managed by SBDebuggers). However, this world did not arrive (mainly due to other commitments on my part), and I now think that if we do want to go in that direction, that we should just create a dummy/empty SBDebugger object for holding the initial SBPlatform.
One benefit of D121605 was the unification of getPlatform and getHostPlatform code paths, and I preserve that benefit by unifying them in the other direction -- using the host SBPlatform for getHostPlatform.
Differential Revision: https://reviews.llvm.org/D138430
show more ...
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
#
56f9cfe3 |
| 05-Aug-2022 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Remove uses of six module (NFC)
With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.
Differential Revision: https://reviews.llvm.org/D131304
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
82ba3f44 |
| 01-Jul-2022 |
Pavel Labath <pavel@labath.sk> |
Recommit "[lldb/test] Don't use preexec_fn for launching inferiors"
This recommits b15b1421, which reverted in was reverted in f51c47d98 due to failures on apple systems. The problem was that the pa
Recommit "[lldb/test] Don't use preexec_fn for launching inferiors"
This recommits b15b1421, which reverted in was reverted in f51c47d98 due to failures on apple systems. The problem was that the patch introduced a race where the debug server could start the attach process before the first process (which isn't supposed to be attached to) was set up. This caused us to attach to the wrong process.
The new version introduces additional synchronization to ensure that does not happen.
Original commit message was: As the documentation states, using this is not safe in multithreaded programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program from the very first instruction, where our usual mechanism of synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test (TestGdbRemoteAttachWait) so instead of doing this everywhere, I create a bespoke solution for that single test. The solution basically consists of outsourcing the preexec_fn code to a separate (and single-threaded) shim process, which enables attaching and then executes the real program.
This pattern could be generalized in case we needed to use it for other tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit a997a1d7fbe229433fb458bb0035b32424ecf3bd.
show more ...
|
#
f51c47d9 |
| 05-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
Revert "[lldb/test] Don't use preexec_fn for launching inferiors"
This reverts commit b15b1421bc9a11b318b65b489e5fd58dd917db1f because it breaks GreenDragon [1]. The bot has been red for several day
Revert "[lldb/test] Don't use preexec_fn for launching inferiors"
This reverts commit b15b1421bc9a11b318b65b489e5fd58dd917db1f because it breaks GreenDragon [1]. The bot has been red for several days, so reverting to green while I take a look.
[1] https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45012/
show more ...
|
#
b15b1421 |
| 01-Jul-2022 |
Pavel Labath <pavel@labath.sk> |
[lldb/test] Don't use preexec_fn for launching inferiors
As the documentation states, using this is not safe in multithreaded programs, and I have traced it to a rare deadlock in some of the tests.
[lldb/test] Don't use preexec_fn for launching inferiors
As the documentation states, using this is not safe in multithreaded programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program from the very first instruction, where our usual mechanism of synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test (TestGdbRemoteAttachWait) so instead of doing this everywhere, I create a bespoke solution for that single test. The solution basically consists of outsourcing the preexec_fn code to a separate (and single-threaded) shim process, which enables attaching and then executes the real program.
This pattern could be generalized in case we needed to use it for other tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit a997a1d7fbe229433fb458bb0035b32424ecf3bd.
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
21c5bb0a |
| 14-Mar-2022 |
Pavel Labath <pavel@labath.sk> |
Recommit [lldb/test] Make category-skipping logic "platform"-independent
This recommits dddf4ce03, which was reverted because of a couple of test failures on macos. The reason behind the failures wa
Recommit [lldb/test] Make category-skipping logic "platform"-independent
This recommits dddf4ce03, which was reverted because of a couple of test failures on macos. The reason behind the failures was that the patch inadvertenly changed the value returned by the host platform from "macosx" to "darwin". The new version fixes that.
Original commit message was:
The decision which categories are relevant for a particular test run happen very early in the test setup process. They use the SBPlatform object to determine which categories should be skipped. The platform object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in <https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594> -- when platform objects are tied to a specific (SB)Debugger, they need to be created alongside it, which currently happens in the test setUp method.
This patch is the first step in that direction -- it rewrites the category skipping logic to avoid depending on a global SBPlatform object. Fortunately, the skipping logic is fairly simple (and I believe it outght to stay that way) and mainly consists of comparing the platform name against some hardcoded lists. This patch bases this comparison on the platform name instead of the os part of the triple (as reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
show more ...
|
#
be09f837 |
| 15-Mar-2022 |
Pavel Labath <pavel@labath.sk> |
Revert "[lldb/test] Make category-skipping logic "platform"-independent"
This reverts commit dddf4ce034a8e06cc1351492dceece3fa2344c14. It breaks a couple of tests on macos.
|
#
dddf4ce0 |
| 14-Mar-2022 |
Pavel Labath <pavel@labath.sk> |
[lldb/test] Make category-skipping logic "platform"-independent
The decision which categories are relevant for a particular test run happen very early in the test setup process. They use the SBPlatf
[lldb/test] Make category-skipping logic "platform"-independent
The decision which categories are relevant for a particular test run happen very early in the test setup process. They use the SBPlatform object to determine which categories should be skipped. The platform object created for this purpose transcends individual test runs.
This setup is not compatible with the direction discussed in <https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594> -- when platform objects are tied to a specific (SB)Debugger, they need to be created alongside it, which currently happens in the test setUp method.
This patch is the first step in that direction -- it rewrites the category skipping logic to avoid depending on a global SBPlatform object. Fortunately, the skipping logic is fairly simple (and I believe it outght to stay that way) and mainly consists of comparing the platform name against some hardcoded lists. This patch bases this comparison on the platform name instead of the os part of the triple (as reported by the platform).
Differential Revision: https://reviews.llvm.org/D121605
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
#
a997a1d7 |
| 14-Jan-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/test] Ensure launched processes are ready to be attached
Linux systems can be configured (and most of them are configured that way) to disable attaching to unrelated processes, /unless/ those
[lldb/test] Ensure launched processes are ready to be attached
Linux systems can be configured (and most of them are configured that way) to disable attaching to unrelated processes, /unless/ those processes explicitly allow that.
Our test inferiors do that by explicitly calling prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY) (a.k.a., lldb_enable_attach). This requires additional synchronization to ensure that the test does not attempt attach before that statement is executed.
This is working fine (albeit cumbersome) for most tests but TestGdbRemoteAttachWait is special in that it wants to start the inferior _after_ issuing the attach request. This means that the usual synchronization method does not work.
This patch introduces a different solution -- enable attaching in the test harness, before the process is launched. Besides fixing this problem, this is also better because it avoids the need to add special code to each attach test (which is a common error).
One gotcha here is that it won't work for remote test suites, as we don't control launching there. However, we could add a similar option to lldb-platform, or require that lldb-platform itself is started with attaching enabled. At that point we could delete all lldb_enable_attach logic.
show more ...
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
26a8e850 |
| 05-Nov-2020 |
Raphael Isemann <teemperor@gmail.com> |
[lldb] Add Apple simulator platforms to lldbplatform.py
This just adds the simulator platforms to the lldbplatform enumerations and the respective test decorator.
The platform names for the simulat
[lldb] Add Apple simulator platforms to lldbplatform.py
This just adds the simulator platforms to the lldbplatform enumerations and the respective test decorator.
The platform names for the simulator are just the SDK names since D85537, so that's why we are not using LLDB's usual platform names here (e.g., SDK = "iphonesimulator" vs LLDB platform ="ios-simulator").
Also removes the duplicate platform enumaration in lldbplatformutil.py.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D89694
show more ...
|