bcm5719-llvm/lldb/source/Target, branch meklort-10.0.1

Add missing nullptr checks.

2020-01-10T16:52:46+00:00

GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses. Inspired by rdar://problem/58317195 Differential Revision: https://reviews.llvm.org/D72413

[lldb] Modernize OptionValue::SetValueChangedCallback

2020-01-09T13:17:17+00:00

instead of a function pointer + void*, take a std::function. This removes a bunch of repetitive, unsafe void* casts.

[lldb][NFC] Use static_cast instead of reinterpret_cast where possible

2020-01-07T12:03:56+00:00

Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161

[NFC] Fixes -Wrange-loop-analysis warnings

2020-01-01T19:01:37+00:00

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857

In 'thread step-out' command, only insert a breakpoint in executable memory.

2019-12-20T19:02:24+00:00

Previously, if the current function had a nonstandard stack layout/ABI, and had a valid data pointer in the location where the return address is usually located, data corruption would occur when the breakpoint was written. This could lead to an incorrectly reported crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts. Differential Revision: https://reviews.llvm.org/D71372

ThreadPlanTracer::TracingStarted can't call virtual methods on Thread.

2019-12-20T18:56:39+00:00

TracingStarted gets called in the Thread constructor, which means you can't call a virtual method of the class. So delay setting up the m_register_values till you need them. NFC as lldb just crashes if you don't do this. The thread tracing is an only occasionally useful feature, and it only sort of works. I'm not adding tests etc. at this point, I'm just poking at it a bit. If I get it working better I'll write tests and so forth.

[lldb] Fix a -Wreturn-type warning on gcc

2019-12-20T14:19:41+00:00

[lldb] Remove modern-type-lookup

2019-12-17T11:24:31+00:00

Summary: As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup. This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around for now). The motivation for this is that I don't think that the current approach of implementing modern-type-lookup will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has so far made the transition work much more complicated than it has to be. A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring and actually testing the existing code we have. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html Reviewers: shafik, martong Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss Tags: #lldb Differential Revision: https://reviews.llvm.org/D71562

[lldb] Fix unused variable warning in ThreadPlanStepRange.cpp

2019-12-17T07:53:06+00:00

This was added in 434905b97d961531286d4b49c7ee1969f7cbea0e. Remove it to fix the compiler warnings for this.

Run all threads when extending a next range over a call.

2019-12-17T01:45:21+00:00

If you don't do this you end up running arbitrary code with only one thread allowed to run, which can cause deadlocks. Differential Revision: https://reviews.llvm.org/D71440