summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Utility
Commit message (Collapse)AuthorAgeFilesLines
* RangeDataVector: Support custom sorting for D63540Jan Kratochvil2020-01-101-0/+42
| | | | | | | | | | | 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
* [lldb] Add a SubsystemRAII that takes care of calling Initialize and ↵Raphael Isemann2019-12-232-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Terminate in the unit tests 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
* [LLDB] Replacing use of ul suffix in GetMaxU64Bitfield since it not ↵shafik2019-12-051-1/+10
| | | | | | | | guarenteed to be 64 bit 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
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-051-31/+27
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream 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
* Avoid triple corruption while merging core infoMuhammad Omair Javaid2019-12-051-0/+35
| | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Remove some (almost) unused Stream::operator<<'sPavel Labath2019-12-041-9/+0
| | | | llvm::raw_ostream provides equivalent functionality.
* [lldb] Add test for Stream::Address and Stream::AddressRangeRaphael Isemann2019-12-041-0/+92
| | | | | I'm refactoring those functions, so we should have some tests for them before doing that.
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-041-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Add FileSpec::Equal unit testsPavel Labath2019-11-281-0/+20
| | | | this is in preparation of a refactor of this method.
* [lldb] Simplify and improve FileSpecTestPavel Labath2019-11-281-24/+24
| | | | | | | | | | | | | | | | | | 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
* [lldb] remove unsigned Stream::operator<< overloadsPavel Labath2019-11-261-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I recently re-discovered that the unsinged stream operators of the lldb_private::Stream class have a surprising behavior in that they print the number in hex. This is all the more confusing because the "signed" versions of those operators behave normally. Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream wrapper, I think we should delete most of our formatting capabilities and just delegate to that. This patch tests the water by just deleting the operators with the most surprising behavior. Most of the code using these operators was printing user_id_t values. It wasn't fully consistent about prefixing them with "0x", but I've tried to consistenly print it without that prefix, to make it more obviously different from pointer values. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70241
* Add arm64_32 support to lldb, an ILP32 codegen Jason Molenda2019-10-161-0/+16
| | | | | | | | | | that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
* ProcessInstanceInfoMatch: Don't match processes with no name if a name match ↵Pavel Labath2019-10-111-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | was requested, take 2 Summary: The previous attempt at making nameless process not match when searching for a given name failed because the macos implementation was depending on this detail in its partial matching strategy. Doing partial matching to avoid expensive lookups is a perfectly valid thing to do, the way it was implemented seems somewhat unexpected. This patch implements it differently by providing special methods in the ProcessInstanceInfoMatch which match only a subset of fields, and changes mac host code to use those instead. Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a name *not* match a nameless process. Reviewers: JDevlieghere, teemperor, jingham Subscribers: wallace, lldb-commits Differential Revision: https://reviews.llvm.org/D68631 llvm-svn: 374529
* [lldb] Fix out of bounds read in DataExtractor::GetCStr and add unit test ↵Raphael Isemann2019-10-101-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | that function. Summary: The `if (*cstr_end == '\0')` in the previous code checked if the previous loop terminated because it found a null terminator or because it reached the end of the data. However, in the case that we hit the end of the data before finding a null terminator, `cstr_end` points behind the last byte in our data and `*cstr_end` reads the memory behind the array (which may be uninitialised) This patch just rewrites that function use `std::find` and adds the relevant unit tests. Reviewers: labath Reviewed By: labath Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68773 llvm-svn: 374311
* Revert "ProcessInstanceInfoMatch: Don't match processes with no name if a ↵Jonas Devlieghere2019-10-081-17/+0
| | | | | | | | name match was requested" This breaks TestProcessAttach and TestHelloWorld on Darwin. llvm-svn: 374008
* ProcessInstanceInfoMatch: Don't match processes with no name if a name match ↵Pavel Labath2019-10-071-0/+17
| | | | | | | | | | | | | | | | | | | | | | | was requested Since D68289, a couple of tests on linux started being extremely flaky. All of them were doing name-based attaching and were failing because they couldn't find an unambiguous process to attach to. The patch above changed the process finding logic, so that failure to find a process name does not constitute an error. This meant that a lot more transient processes showed up in the process list during the test suite run. Previously, these processes would not appear as they would be gone by the time we went to read their executable name, arguments, etc. Now, this alone should not cause an issue were it not for the fact that we were considering a process with no name as if it matched by default (even if we were explicitly searching for a process with a specified name). This meant that any of the "transient" processes with no name would make the name match ambiguous. That clearly seems like a bug to me so I fix that. llvm-svn: 373925
* [process list] make the TRIPLE column widerWalter Erquinigo2019-10-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that `process list` works better on the android platform, the arch aarch64-unknown-linux-android appears quite often. The existing printed width of the TRIPLE column is not long enough, which doesn't look okay. E.g. ``` 1561 1016 aarch64-unknown-linux-android ip6tables-restore 1999 1 aarch64-unknown-linux-android tlc_server 2332 982 com.android.systemui 2378 983 webview_zygote ``` Now, after adding 6 spaces, it looks better ``` PID PARENT USER TRIPLE NAME ====== ====== ========== ============================== ============================ ... 1561 1016 aarch64-unknown-linux-android ip6tables-restore 1999 1 aarch64-unknown-linux-android tlc_server 2332 982 com.android.systemui 2378 983 webview_zygote 2448 982 com.sec.location.nsflp2 ``` Reviewers: clayborg, labath, xiaobai, aadsm Reviewed By: labath Subscribers: srhines, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68291 llvm-svn: 373670
* [JSON] Remove Utility/JSON.{h|cpp}Jonas Devlieghere2019-10-022-27/+0
| | | | | | | | | | | | | This patch is the final step in my quest to get rid of the JSON parser in LLDB. Vedant's coverage report [1] shows that it was mostly untested. Furthermore, the LLVM implementation has a much nicer API and using it means one less thing to maintain for LLDB. [1] http://lab.llvm.org:8080/coverage/coverage-reports/index.html Differential revision: https://reviews.llvm.org/D68305 llvm-svn: 373501
* Use llvm for dumping DWARF expressionsPavel Labath2019-09-301-1/+3
| | | | | | | | | | | | | | | Summary: It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo structs (which is what is needed to turn dwarf register numbers into strings). Reviewers: JDevlieghere, aprantl, jasonmolenda Subscribers: tatyana-krasnukha, lldb-commits Differential Revision: https://reviews.llvm.org/D67966 llvm-svn: 373208
* [Reproducer] Use // in the unit testsJonas Devlieghere2019-09-271-13/+13
| | | | | | This should be a valid absolute path on both POSIX and Windows. llvm-svn: 373124
* [Reproducer] Update the unit tests to specify the path style.Jonas Devlieghere2019-09-271-17/+33
| | | | | | | The unit tests started failing on Windows after my recent patch that ensured we always deal with absolute paths. This should fix that. llvm-svn: 373114
* [lldb][NFC] Add CompletionRequest::AppendEmptyArgumentRaphael Isemann2019-09-251-11/+3
| | | | | | | | | This is the only legitimate use we currently have for modifying a CompletionRequest. Add a utility function for this purpose and remove the remaining setters which go against the idea of having an immutable CompletionRequest. llvm-svn: 372858
* [lldb] Remove redundant argument lists in CompletionRequestRaphael Isemann2019-09-241-8/+8
| | | | | | | | | | | We currently have two lists in the CompletionRequest that we inherited from the old API: The complete list of arguments ignoring where the user requested completion and the list of arguments that stops at the cursor. Having two lists of arguments is confusing and can lead to subtle errors, so let's remove the complete list until we actually need it. llvm-svn: 372692
* [lldb][NFC] Make cursor char position unsigned in CompletionRequestRaphael Isemann2019-09-231-3/+3
| | | | | | | This was only an 'int' because to fit into the old API which is gone by now. llvm-svn: 372568
* [lldb] Make cursor index in CompletionRequest unsignedRaphael Isemann2019-09-231-2/+20
| | | | | | | | | | | | The fact that index==-1 means "no arguments" is not obvious and only used in one place from what I can tell. Also fixes several warnings about using the cursor index as if it was a size_t when comparing. Not fully NFC as we now also correctly update the partial argument list when injecting the fake empty argument in the CompletionRequest constructor. llvm-svn: 372566
* [lldb][NFC] Remove argument prefix checking boilerplate when adding completionsRaphael Isemann2019-09-231-0/+37
| | | | llvm-svn: 372561
* [lldb] Reduce some dangerous boilerplate with CompletionRequest::ShiftArgumentsRaphael Isemann2019-09-231-0/+35
| | | | | | | | | | | | | We should in general not allow external code to fiddle with the internals of CompletionRequest, but until this is gone let's at least provide a utility function that makes this less dangerous. This also now correct updates the partially parsed argument list, but it doesn't seem to be used by anything that is behind one of the current shift/SetCursorIndex calls, so this doesn't seeem to fix any currently used completion. llvm-svn: 372556
* [lldb] Remove SetCount/ClearCount from FlagsRaphael Isemann2019-09-161-38/+3
| | | | | | | | | | | | | | | | | | Summary: These functions are only used in tests where we should test the actual flag values instead of counting all bits for an approximate check. Also these popcount implementation aren't very efficient and doesn't seem to be optimised to anything fast. Reviewers: davide, JDevlieghere Reviewed By: davide, JDevlieghere Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67540 llvm-svn: 372018
* [lldb][NFC] Remove ArgEntry::ref memberRaphael Isemann2019-09-131-3/+3
| | | | | | | | | | | The StringRef should always be identical to the C string, so we might as well just create the StringRef from the C-string. This might be slightly slower until we implement the storage of ArgEntry with a string instead of a std::unique_ptr<char[]>. Until then we have to do the additional strlen on the C string to construct the StringRef. llvm-svn: 371842
* Implement DW_OP_convertAdrian Prantl2019-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | This patch adds basic support for DW_OP_convert[1] for integer types. Recent versions of LLVM's optimizer may insert this opcode into DWARF expressions. DW_OP_convert is effectively a type cast operation that takes a reference to a base type DIE (or zero) and then casts the value at the top of the DWARF stack to that type. Internally this works by changing the bit size of the APInt that is used as backing storage for LLDB's DWARF stack. I managed to write a unit test for this by implementing a mock YAML object file / module that takes debug info sections in yaml2obj format. [1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1 <rdar://problem/48167864> Differential Revision: https://reviews.llvm.org/D67369 llvm-svn: 371532
* [Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`Jonas Devlieghere2019-09-102-47/+0
| | | | | | | | | This removes the CleanUp class and replaces its usages with llvm's ScopeExit, which has similar semantics. Differential revision: https://reviews.llvm.org/D67378 llvm-svn: 371474
* [lldb][NFC] Extend ArgsTestRaphael Isemann2019-09-061-0/+68
| | | | llvm-svn: 371180
* Move ProcessInstanceInfoTest to UtilityPavel Labath2019-08-262-0/+94
| | | | | | The class under test was moved in r355342. This moves the test code too. llvm-svn: 369907
* [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann2019-08-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
* [NFC] Return llvm::StringRef from StringExtractor::GetStringRef.Jonas Devlieghere2019-08-211-39/+38
| | | | | | | | | | This patch removes the two variant of StringExtractor::GetStringRef that return (non-)const references to std::string. The non-const one was being abused to reinitialize the StringExtractor and its uses are replaced by calls to the copy asignment operator. The const variant was refactored to return an actual llvm::StringRef. llvm-svn: 369493
* [NFC] Remove lldb_utility namespace.Jonas Devlieghere2019-08-212-2/+2
| | | | | | | While generating the Doxygen I noticed this lone namespace that has one class and one function in it. This moves them into lldb_private. llvm-svn: 369485
* [lldb][NFC] Stop using GetNumberOfMatches in CompletionRequest testRaphael Isemann2019-08-191-14/+14
| | | | | | | | This function is just a wrapper for GetNumberOfResults and will be removed soon. This patch just changes all calls to GetNumberOfResults where possible (which is currently just the unit test). llvm-svn: 369267
* [lldb][NFC] Address review comments to StringList for-loop supportRaphael Isemann2019-08-191-1/+1
| | | | llvm-svn: 369237
* [Utility] Reimplement RegularExpression on top of llvm::RegexJonas Devlieghere2019-08-163-3/+69
| | | | | | | | | | | | | | | Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I noticed that there are several places where need the regular expression string. So instead I propose to keep the RegularExpression class and make it a thin wrapper around llvm::Regex. This patch also removes the workaround for empty regular expressions. The result is that we are now (more or less) POSIX conformant. Differential revision: https://reviews.llvm.org/D66174 llvm-svn: 369153
* [lldb][NFC] Allow for-ranges on StringListRaphael Isemann2019-08-161-0/+18
| | | | llvm-svn: 369113
* [CompletionRequest] Remove unimplemented members.Jonas Devlieghere2019-07-311-9/+4
| | | | | | | | | | Completion requests have two fields that are essentially unimplemented: `m_match_start_point` and `m_max_return_elements`. This would've been okay, if it wasn't for the fact that this caused a bunch of useless parameters to be passed around. Occasionally there would be a comment or assert saying that they are not supported. This patch removes them. llvm-svn: 367385
* [StringList] Change LongestCommonPrefix APIJonas Devlieghere2019-07-311-10/+5
| | | | | | | | | When investigating a completion bug I got confused by the API. LongestCommonPrefix finds the longest common prefix of the strings in the string list. Instead of returning that string through an output argument, just return it by value. llvm-svn: 367384
* [Support] move FileCollector from LLDB to llvm/SupportAlex Lorenz2019-07-242-215/+0
| | | | | | | | | The file collector class is useful for creating reproducers, not just for LLDB, but for other tools as well in LLVM/Clang. Differential Revision: https://reviews.llvm.org/D65237 llvm-svn: 366956
* [Reproducers] Make reproducer relocatableJonas Devlieghere2019-06-181-3/+3
| | | | | | | | | | | | | | Before this patch, reproducers weren't relocatable. The reproducer contained hard coded paths in the VFS mapping, as well in the yaml file listing the different input files for the command interpreter. This patch changes that: - Use relative paths for the DataCollector. - Use an overlay prefix for the FileCollector. Differential revision: https://reviews.llvm.org/D63467 llvm-svn: 363697
* [Reproducers] Simplify providers with nested Info struct (NFC)Jonas Devlieghere2019-06-121-9/+7
| | | | | | | | | This replaces the `info` typedef with a nested struct named Info. This means we now have FooProvider and FooProvider::Info, instead of two related but separate classes FooProvider and FooInfo. This change is mostly cosmetic. llvm-svn: 363211
* Silence 'warning C4305: 'initializing': truncation from 'double' to 'float'' ↵Alexandre Ganea2019-06-031-6/+6
| | | | | | with MSVC 19.16.27021.1 (VS2017 15.9.12) llvm-svn: 362437
* Remove length modifier when using assignment suppression in TimerTestAntonio Afonso2019-05-301-2/+2
| | | | | | | | | | | | | | | | Summary: This is useless and it's giving warnings in the build bots: /home/motus/netbsd8/netbsd8/llvm/tools/lldb/unittests/Utility/TimerTest.cpp:67:43: warning: use of assignment suppression and length modifier together in gnu_scanf format [-Wformat=] Reviewers: xiaobai Subscribers: krytarowski, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62626 llvm-svn: 362107
* Add more information to the log timer dumpAntonio Afonso2019-05-291-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `log timer dump` is showing the time of the function itself minus any function that is called from this one that also happens to be timed. However, this is really not obvious and it also makes it hard to understand the time spent in total and also which children are actually taking the time. To get a better reading of the timer dump I added the total, children (which I named child) and also the hit count. I used these timers to figure out a performance issue and only after adding this things were more clear to me. It looks like this: ``` (lldb) log timer dump 35.447713617 sec (total: 35.449s; child: 0.001s; count: 1374) for void SymbolFileDWARF::Index() 29.717921481 sec (total: 29.718s; child: 0.000s; count: 8230500) for const lldb_private::ConstString &lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const 21.049508865 sec (total: 24.683s; child: 3.633s; count: 1399) for void lldb_private::Symtab::InitNameIndexes() ... ``` Reviewers: clayborg, teemperor, labath, espindola, xiaobai Reviewed By: labath, xiaobai Subscribers: emaste, mgorny, arichardson, eraman, MaskRay, jdoerfert, labath, davide, teemperor, aprantl, erik.pilkington, jfb, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61235 llvm-svn: 361987
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* [Reproducers] Fix reproducer unittestJonas Devlieghere2019-05-081-1/+3
| | | | | | | | | | | | | | | I think the recent change to flush the SB API recording uncovered a real issue on the Windows bot. Although I couldn't make much sense of the error message "unknown file: error: SEH exception with code 0x3221225477 thrown in the test body.", it prompted me to look at the test. In the unit test we were recording during replay, which is obviously not correct. I think we didn't see this issue before because we flushed once after the recording was done. This patch unsets the recording logic during the replay part of the test. Hopefully this fixed the Windows bot. llvm-svn: 360298
OpenPOWER on IntegriCloud