Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-10T14:14:38+00:00 2020-01-10T14:14:38+00:00 Jan Kratochvil jan.kratochvil@redhat.com 2020-01-10T14:14:38+00:00 urn:sha1:2f2f41e12c5201b600d887d22ce5cb4afd2ff594 As suggested by @labath extended RangeDataVector so that user can provide custom sorting of the Entry's `data' field for D63540. https://reviews.llvm.org/D63540 RangeData functions were used just by RangeDataVector (=after I removed them LLDB still builds fine) which no longer uses them so I removed them. Differential revision: https://reviews.llvm.org/D72460 2019-12-23T09:38:25+00:00 Raphael Isemann teemperor@gmail.com 2019-12-23T09:38:12+00:00 urn:sha1:5dca0596a959217a1c18858a62ed35245a4c42b4 Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630 2019-12-05T18:03:53+00:00 shafik syaghmour@apple.com 2019-12-05T17:28:08+00:00 urn:sha1:fffd70291e124efc4a5bd475dccfc41cbc4bca8a GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit. Differential Revision: https://reviews.llvm.org/D70992 2019-12-05T13:41:33+00:00 Raphael Isemann teemperor@gmail.com 2019-12-05T13:41:09+00:00 urn:sha1:1462f5a4c138bb20f38a579a29d12ab4e5fb6191 Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052 2019-12-05T08:10:04+00:00 Muhammad Omair Javaid omair.javaid@linaro.org 2019-12-05T08:04:04+00:00 urn:sha1:8b8185bb1b456e0ccf7b1ed1f00bc646853ab004 Summary: This patch fixes a bug where when target triple created from elf information is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging both triple results in armv8l--unknown-unknown. This happens because we order a triple update while calling CoreUpdated and CoreUpdated creates a new triple with no vendor or environment information. Making sure we do not update triple and just update to more specific core fixes the issue. Reviewers: labath, jasonmolenda, clayborg Reviewed By: jasonmolenda Subscribers: jankratochvil, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70155 2019-12-04T10:07:46+00:00 Pavel Labath pavel@labath.sk 2019-11-26T13:45:15+00:00 urn:sha1:150c8dd13be4a9d9a9f631a507871359117871ca llvm::raw_ostream provides equivalent functionality. 2019-12-04T09:45:30+00:00 Raphael Isemann teemperor@gmail.com 2019-12-04T09:27:18+00:00 urn:sha1:16d20130444c9601ad276a8e82f79b2ac204c6f6 I'm refactoring those functions, so we should have some tests for them before doing that. 2019-12-04T09:42:32+00:00 Pavel Labath pavel@labath.sk 2019-11-29T10:31:00+00:00 urn:sha1:532290e69fcb0e1f2005853241bc2cac6941e0f7 Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851 2019-11-28T13:31:52+00:00 Pavel Labath pavel@labath.sk 2019-11-28T12:47:58+00:00 urn:sha1:bf716eb807409adf6490cb1cf595fb51efbd3fe6 this is in preparation of a refactor of this method. 2019-11-28T13:31:29+00:00 Pavel Labath pavel@labath.sk 2019-11-28T12:30:39+00:00 urn:sha1:d1a561d446809cc3b5c11c163b9aa5ba4957af68 Summary: A most of these tests create FileSpecs with a hardcoded style. Add utility functions which create a file spec of a given style to simplify things. While in there add SCOPED_TRACE messages to tests which loop over multiple inputs to ensure it's clear which of the inputs failed. Reviewers: teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70814