Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-17T10:08:52+00:00 2019-12-17T10:08:52+00:00 Pavel Labath pavel@labath.sk 2019-12-16T13:15:11+00:00 urn:sha1:dcd14324dced7d91aa8bf78a607055ca093b27bf Previously each test was annotated manually. This does the same thing. 2019-12-16T13:10:42+00:00 Pavel Labath pavel@labath.sk 2019-12-16T13:09:09+00:00 urn:sha1:755a66ebdeda38669f5498565cbc6af331b47bad The is the best method we have at the moment for attach-style tests. 2019-12-13T11:23:04+00:00 Raphael Isemann teemperor@gmail.com 2019-12-13T11:11:23+00:00 urn:sha1:a52a11139c0e3db9b00079aa1516080742b79475 Summary: A lot of tests do this trick but the vast majority of them don't even call `print()`. Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file. I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives). I also corrected the additional empty lines after the import in the files that I manually edited. Reviewers: JDevlieghere, labath, jfb Reviewed By: labath Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71452 2019-12-09T18:43:50+00:00 Serhiy Redko serhiy.redko@oculus.com 2019-12-08T04:11:35+00:00 urn:sha1:6dad5e441db5400a9716fd3c6f943ceeeecdfe4e "The debug adapter supports the delayed loading of parts of the stack, which requires that both the 'startFrame' and 'levels' arguments and the 'totalFrames' result of the 'StackTrace' request are supported." Lack of this field makes VSCode incorrectly display stack traces information D71034 2019-12-09T14:08:59+00:00 Muhammad Omair Javaid omair.javaid@linaro.org 2019-12-09T14:07:14+00:00 urn:sha1:0964733bae2d0823f7b431ee2b16a3fd1dd993e3 This patch removes xfail decorator from some lldb testcases which are passing steadily now for past few week/months on aarch64/linux buildbot. 2019-11-26T15:46:21+00:00 Michał Górny mgorny@gentoo.org 2019-11-26T15:45:43+00:00 urn:sha1:3cd9a8b7dc61e3ca5829225548d6346b8a5a25bb 2019-11-25T19:11:58+00:00 Michał Górny mgorny@gentoo.org 2019-07-12T17:11:31+00:00 urn:sha1:8d9400b65b972cb50fe2266360443192ea107ec9 Implement major improvements to multithreaded program support. Notably, support tracking new and exited threads, associate signals and events with correct threads and support controlling individual threads when resuming. Firstly, use PT_SET_EVENT_MASK to enable reporting of created and exited threads via SIGTRAP. Handle TRAP_LWP events to keep track of the currently running threads. Secondly, update the signal (both generic and SIGTRAP) handling code to account for per-thread signals correctly. Signals delivered to the whole process are reported on all threads, while per-thread signals and events are reported only to the specific thread. The remaining threads are marked as 'stopped with no reason'. Note that NetBSD always stops all threads on debugger events. Thirdly, implement the ability to set every thread as running, stopped or single-stepping separately while continuing the process. This also provides the ability to send a signal to the whole process or to one of its thread while resuming. Differential Revision: https://reviews.llvm.org/D70022 2019-11-25T09:07:38+00:00 Pavel Labath pavel@labath.sk 2019-11-12T16:28:42+00:00 urn:sha1:aa16bf15fe38ae4d12d85e7610891dd48e6c0cda Summary: The test used a non-stopping "run" command to launch the process. This is different from the regular launch with no extra launch commands, which uses eLaunchFlagStopAtEntry to ensure that the process stops straight away. I'm not really sure what's supposed to happen in non-stop-at-entry mode, or if that's even supported, but what ended up happening was the launch packet got a reply while the process was running. Then the test case did a continue_to_next_stop(), which queued a *second* resume request (along with the internal "resumes" which were being issued as a part of normal process startup). These two resumes ended up chasing each other's tails inside lldb in a way which produced hilarious log traces. Surprisingly, the test ended up passing most of the time, but it did cause spurious failures when the test seemed to miss a breakpoint. This changes the test to use stop-at-entry mode in the manual launch sequence too, which seems to be enough to make the test pass reliably. Reviewers: clayborg, kusmour, jankratochvil Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70127 2019-11-20T20:16:34+00:00 Michał Górny mgorny@gentoo.org 2019-11-20T20:16:34+00:00 urn:sha1:923afb4a61708cd6d5c6786c81f55a682ec46497 2019-11-18T21:36:04+00:00 Michał Górny mgorny@gentoo.org 2019-11-18T21:07:02+00:00 urn:sha1:085486779890e394dd42447c7c5b0fb36a79ea2b