Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-27T14:10:11+00:00 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-14T14:19:29+00:00 Pavel Labath pavel@labath.sk 2019-12-23T15:31:36+00:00 urn:sha1:4b5bc38802dcc7d2c6d7f5af1eca1755bd0fd9cb These are the last sections not managed by the DWARFContext object. I also introduce separate SectionType enums for dwo section variants, as this is necessary for proper handling of single-file split dwarf. 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-10T12:29:24+00:00 Pavel Labath pavel@labath.sk 2019-12-21T14:29:57+00:00 urn:sha1:e65282deca8455d1cc6d83b7016af9aa374f9f89 This patch removes the code (deep inside DWARFDebugInfoEntry) which automagically returned the attributes of the dwo unit DIE when asking for the attributes of the skeleton unit. This is fairly hacky, and not consistent with how llvm DWARF parser operates. Instead, I change the code the explicitly request (via GetNonSkeletonUnit) the right unit to search (there were just two places that needed this). If it turns out we need this more often, we can create a utility function (external to DWARFUnit) for doing this. 2020-01-09T12:19:29+00:00 Pavel Labath pavel@labath.sk 2019-12-20T08:42:37+00:00 urn:sha1:cd5da94d80b2b0f2bdb2d0157e24705a4cbd2a4e Summary: Our code was expecting that a single (symbol) file contains only one kind of location lists. This is not correct (on non-apple platforms, at least) as a file can compile units with different dwarf versions. This patch moves the deteremination of location list flavour down to the compile unit level, fixing this problem. I have also tried to rougly align the code with the llvm DWARFUnit. Fully matching the API is not possible because of how lldb's DWARFExpression lives separately from the rest of the DWARF code, but this is at least a step in the right direction. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71751 2020-01-09T12:19:29+00:00 Pavel Labath pavel@labath.sk 2019-12-17T16:12:29+00:00 urn:sha1:9bb01efa49ca7f069bc7acba7e4c9bf64d972e79 Summary: A skeleton unit can easily be detected by checking the m_dwo_symbol_file member, but we cannot tell a split unit from a normal unit from the "inside", which is sometimes useful. This patch adds a m_is_dwo member to enable this, and align the code with llvm::DWARFUnit. Right now it's only used to avoid creating a split unit inside another split unit (which removes one override from SymbolFileDWARFDwo and brings us a step closer to deleting it), but my main motivation is fixing the handling of location lists in mixed v4&v5 files. This comes in a separate patch. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71750 2020-01-09T02:05:33+00:00 Alex Langford apl@fb.com 2020-01-08T23:35:21+00:00 urn:sha1:a63af915288ad9d1049d486833fcd085b620dc6d 2020-01-08T22:32:11+00:00 Adrian Prantl aprantl@apple.com 2020-01-08T22:31:27+00:00 urn:sha1:28b9cdd26073c79be36c79476a9bacceca3d116f https://reviews.llvm.org/D58856 2020-01-02T10:57:00+00:00 Raphael Isemann teemperor@gmail.com 2020-01-02T10:57:00+00:00 urn:sha1:a95f4c87842d76a9fce146b2f25e6c8079f6bbdc 2020-01-02T10:54:45+00:00 Raphael Isemann teemperor@gmail.com 2019-12-30T20:20:01+00:00 urn:sha1:fe8e25a48a2a0f8f508499ba950181dba3d600b0 LLDB frequently converts QualType to CompilerType. This is currently done like this: result = CompilerType(this, qual_type_var.getAsOpaquePtr()) There are a few shortcomings in this current approach: 1. CompilerType's constructor takes a void* pointer so it isn't type safe. 2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type actually belongs to the passed ClangASTContext) without expanding the TypeSystem API. 3. The logic for converting QualType->CompilerType is spread out over all of LLDB so changing it is difficult (e.g., what if we want to just pass the type ptr and not the 1type_ptr | qual_flags1 to CompilerType). This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl functions that does this conversion in a type safe way. It also adds a sanity check for Tag-based types that the type actually belongs to the current ClangASTContext (Types don't seem to know their ASTContext, so we have to workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types we construct but it's better than no sanity check).