Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-28T13:24:36+00:00 2020-01-28T13:24:36+00:00 Pavel Labath pavel@labath.sk 2020-01-24T11:02:43+00:00 urn:sha1:54b022d344412fc9f1dfe37ee05de934a01e1ea4 The test was printing a char[3] variable without a terminating nul. The memory after that variable (an unnamed bitfield) was not initialized. If the memory happened to be nonzero, the summary provider for the variable would run off into the next field. This is probably not the right behavior (it should stop at the end of the array), but this is not the purpose of this test. I have filed pr44649 for this bug, and fixed the test to not depend on this behavior. (cherry picked from commit 77cedb0cdb8623ff9eb22dbf3b9302ee4d9f8a20) 2020-01-27T14:10:11+00:00 shafik syaghmour@apple.com 2020-01-23T22:42:12+00:00 urn:sha1:b5cf892651812003e64c4a8f0dbf81f74a499016 We ran into an assert when debugging clang and performing an expression on a class derived from DeclContext. The assert was indicating we were getting the offsets wrong for RecordDeclBitfields. We were getting both the size and offset of unnamed bit-field members wrong. We could fix this case with a quick change but as I extended the test suite to include more combinations we kept finding more cases that were being handled incorrectly. A fix that handled all the new cases as well as the cases already covered required a refactor of the existing technique. Differential Revision: https://reviews.llvm.org/D72953 (cherry picked from commit fcaf5f6c01a09f23b948afb8c91c4dd951d4525e) 2020-01-14T19:15:48+00:00 Stella Stamenova stilis@microsoft.com 2020-01-14T19:13:22+00:00 urn:sha1:ab72db7fc85266f094cc6b9452dd01f175c04cab After https://reviews.llvm.org/D70846, the test is now passing on Windows 2020-01-14T13:59:56+00:00 Levon Ter-Grigoryan patriosthegreat@protonmail.ch 2020-01-14T13:33:43+00:00 urn:sha1:a705cf1acbe94498f7fcca4e89be6d4820271227 Summary: This change is connected with https://reviews.llvm.org/D69843 In large codebases, we sometimes see Module::FindFunctions (when called from ClangExpressionDeclMap::FindExternalVisibleDecls) returning huge amounts of functions. In current fix I trying to return only function_fullnames from ManualDWARFIndex::GetFunctions when eFunctionNameTypeFull is passed as argument. Reviewers: labath, jarin, aprantl Reviewed By: labath Subscribers: shafik, clayborg, teemperor, arphaman, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70846 2020-01-13T09:40:29+00:00 Raphael Isemann teemperor@gmail.com 2020-01-13T09:00:06+00:00 urn:sha1:ddf044290ede7d7fd47f4f673e3e628f551a8aac Summary: This just adds `NO_DEBUG_INFO_TESTCASE` to tests that don't really exercise anything debug information specific and therefore don't need to be rerun for all debug information variants. Reviewers: labath, jingham, aprantl, mib, jfb Reviewed By: aprantl Subscribers: dexonsmith, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72447 2019-12-13T18:00:59+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-12-13T17:49:51+00:00 urn:sha1:1ef7c4269b453a98cada3ee3d29644e994fbc421 Thanks Ted Woodward for noticing this. 2019-12-13T11:34:49+00:00 Raphael Isemann teemperor@gmail.com 2019-12-13T11:24:23+00:00 urn:sha1:9bace26a690a778ec0f09a9aae9537dfbdb6f42f Summary: A lot of our tests copied the setUp code from our TestSampleTest.py: ``` def setUp(self): # Call super's setUp(). TestBase.setUp(self) ``` This code does nothing unless we actually do any setUp work in there, so let's remove all these method definitions. Reviewers: labath, JDevlieghere Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71454 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-13T07:30:58+00:00 Muhammad Omair Javaid omair.javaid@linaro.org 2019-12-13T07:03:29+00:00 urn:sha1:5536c62f3c35015802dd59150d422c4ab79db581 This patch removes xpass decorator from tests which were failing due to pr44037. pr44037 was fixed by rev 6ce1a897b6a82e18059fd3b75b8d52ff12c2a605 2019-12-11T20:00:16+00:00 Jason Molenda jmolenda@apple.com 2019-12-11T19:43:35+00:00 urn:sha1:6d64162a2d0df2230faf02ff7ee677c448faf4af I don't think this test case can be handled correctly on AAPCS64. The ABI says that the caller passes the address of the return object in x8. x8 is a caller-spilled (aka "volatile") register, and the function is not required to preserve x8 or to copy the address back into x8 on function exit like the SysV x86_64 ABI does with rax. (from aapcs64: "there is no requirement for the callee to preserve the value stored in x8") From my quick reading of ABISysV_arm64, I worry that it may actually be using the value in x8 at function exit, assuming it still has the address of the return object - if (is_return_value) { // We are assuming we are decoding this immediately after returning from // a function call and that the address of the structure is in x8 reg_info = reg_ctx->GetRegisterInfoByName("x8", 0); This will work on trivial test programs / examples, but if the function does another function call, or overwrites x8 as a scratch register, lldb will provide incorrect values to the user. ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value as unavailable so we're providing incorrect values to the user all the time. I expect my fix will be to make ABIMacOSX_arm64 flag the return value as unretrievable, unless I've misread the ABI.