bcm5719-llvm/lldb/packages/Python, branch meklort-10.0.1

[lldb] Fix nondeterminism in TestCppBitfields

2020-01-28T13:24:36+00:00

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)

[LLDB] Fix the handling of unnamed bit-fields when parsing DWARF

2020-01-27T14:10:11+00:00

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)

[lldb] Add expect_expr function for testing expression evaluation in dotests.

2020-01-15T12:04:04+00:00

Summary: This patch adds a new function to lldbtest: `expect_expr`. This function is supposed to replace the current approach of calling `expect`/`runCmd` with `expr`, `p` etc. `expect_expr` allows evaluating expressions and matching their value/summary/type/error message without having to do any string matching that might allow unintended passes (e.g., `self.expect("expr 3+4", substrs=["7"])` can unexpectedly pass for results like `(Class7) $0 = 7`, `(int) $7 = 22`, `(int) $0 = 77` and so on). This only uses the function in a few places to test and demonstrate it. I'll migrate the tests in follow up commits. Reviewers: JDevlieghere, shafik, labath Reviewed By: labath Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70314

[lldb/test] Add test for CMTime data formatter

2020-01-15T07:11:15+00:00

Add a test for the CMTime data formatter. The coverage report showed that this code path was untested.

dotest.py: Add option to pass extra lldb settings to dotest

2020-01-14T20:35:24+00:00

The primary motivation for this is to add another dimension to the Swift LLDB test matrix, but this seems generally useful. Differential Revision: https://reviews.llvm.org/D72662

[lldb/test] test_breakpoints_func_full from TestNamespace.NamespaceBreakpointTestCase is now passing on Windows

2020-01-14T19:15:48+00:00

After https://reviews.llvm.org/D70846, the test is now passing on Windows

Expression eval lookup speedup by not returning methods in ManualDWARFIndex::GetFunctions

2020-01-14T13:59:56+00:00

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

[lldb/Expression] Improve interpreter error message with a non-running target

2020-01-14T12:06:58+00:00

When trying to interpret an expression with a function call, if the process hasn't been launched, the expression fails to be interpreted and the user gets the following error message: ```error: Can't run the expression locally``` This message doesn't explain why the expression failed to be interpreted, that's why this patch improves the error message that is displayed when trying to run an expression while no process is running. rdar://11991708 Differential Revision: https://reviews.llvm.org/D72510 Signed-off-by: Med Ismail Bennani

[lldb][NFC] Rewrite python_api/rdar-12481949 test

2020-01-14T09:10:24+00:00

Summary: This renames the test `rdar-12481949` to `get-value-32bit-int` as it just tests that we return the correct result get calling GetValueAsSigned/GetValueAsUnsigned on 32-bit integers. It also deletes all the strange things going on in this test including resetting the data formatters (which are to my knowledge not used to calculate scalar values) and testing Python's long integers (let's just assume that our Python distribution works correctly). Also modernises the setup code. Reviewers: labath, aprantl Reviewed By: aprantl Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72593

[lldb] Fix that SBThread.GetStopDescription is returning strings with uninitialized memory at the end.

2020-01-14T08:34:32+00:00

Summary: `SBThread.GetStopDescription` is a curious API as it takes a buffer length as a parameter that specifies how many bytes the buffer we pass has. Then we fill the buffer until the specified length (or the length of the stop description string) and return the string length. If the buffer is a nullptr however, we instead return how many bytes we would have written to the buffer so that the user can allocate a buffer with the right size and pass that size to a subsequent `SBThread.GetStopDescription` call. Funnily enough, it is not possible to pass a nullptr via the Python SWIG bindings, so that might be the first API in LLDB that is not only hard to use correctly but impossible to use correctly. The only way to call this function via Python is to throw in a large size limit that is hopefully large enough to contain the stop description (otherwise we only get the truncated stop description). Currently passing a size limit that is smaller than the returned stop description doesn't cause the Python bindings to return the stop description but instead the truncated stop description + uninitialized characters at the end of the string. The reason for this is that we return the result of `snprintf` from the method which returns the amount of bytes that *would* have been written (which is larger than the buffer). This causes our Python bindings to return a string that is as large as full stop description but the buffer that has been filled is only as large as the passed in buffer size. This patch fixes this issue by just recalculating the string length in our buffer instead of relying on the wrong return value. We also have to do this in a new type map as the old type map is also used for all methods with the given argument pair `char *dst, size_t dst_len` (e.g. SBProcess.GetSTDOUT`). These methods have different semantics for these arguments and don't null-terminate the returned buffer (they instead return the size in bytes) so we can't change the existing typemap without breaking them. Reviewers: labath, jingham Reviewed By: labath Subscribers: clayborg, shafik, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72086