summaryrefslogtreecommitdiffstats
path: root/lldb/source/Utility
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace LLDB's LEB128 implementation with the one from LLVMRaphael Isemann2018-08-031-35/+9
| | | | | | | | | | | | Reviewers: davide, labath Reviewed By: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D50162 llvm-svn: 338920
* Add raw_ostream wrapper to the Stream classRaphael Isemann2018-08-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This wrapper will allow us in the future to reuse LLVM methods from within the Stream class. Currently no test as this is intended to be an internal class that shouldn't have any NFC. The test for this change will be the follow up patch that migrates LLDB's LEB128 implementation to the one from LLVM. This change also adds custom move/assignment methods to Stream, as LLVM raw_ostream doesn't support these. As our internal stream has anyway no state, we can just keep the same stream object around. Reviewers: davide, labath Reviewed By: labath Subscribers: xiaobai, labath, lldb-commits Differential Revision: https://reviews.llvm.org/D50161 llvm-svn: 338901
* Add byte counting mechanism to LLDB's Stream class.Raphael Isemann2018-08-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch allows LLDB's Stream class to count the bytes it has written to so far. There are two major motivations for this patch: The first one is that this will allow us to get rid of all the handwritten byte counting code we have in LLDB so far. Examples for this are pretty much all functions in LLDB that take a Stream to write to and return a size_t, which usually represents the bytes written. By moving to this centralized byte counting mechanism, we hopefully can avoid some tricky errors that happen when some code forgets to count the written bytes while writing something to a stream. The second motivation is that this is needed for the migration away from LLDB's `Stream` and towards LLVM's `raw_ostream`. My current plan is to start offering a fake raw_ostream class that just forwards to a LLDB Stream. However, for this raw_ostream wrapper we need to fulfill the raw_ostream interface with LLDB's Stream, which currently lacks the ability to count the bytes written so far (which raw_ostream exposes by it's `tell()` method). By adding this functionality it is trivial to start rolling out our raw_ostream wrapper (and then eventually completely move to raw_ostream). Also, once this fake raw_ostream is available, we can start replacing our own code writing to LLDB's Stream by LLVM code writing to raw_ostream. The best example for this is the LEB128 encoding we currently ship, which can be replaced with by LLVM's version which accepts an raw_ostream. From the point of view of the pure source changes this test does, we essentially just renamed the Write implementation in Stream to `WriteImpl` while the `Write` method everyone is using to write its raw bytes is now just forwarding and counting the written bytes. Reviewers: labath, davide Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D50159 llvm-svn: 338733
* Fix out-of-bounds read in Stream::PutCStringAsRawHex8Raphael Isemann2018-08-011-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: When I added the Stream unit test (r338488), the build bots failed due to an out-of- bound reads when passing an empty string to the PutCStringAsRawHex8 method. In r338491 I removed the test case to fix the bots. This patch fixes this in PutCStringAsRawHex8 by always checking for the terminating null character in the given string (instead of skipping it the first time). It also re-adds the test case I removed. Reviewers: vsk Reviewed By: vsk Subscribers: vsk, lldb-commits Differential Revision: https://reviews.llvm.org/D50149 llvm-svn: 338637
* Don't ignore byte_order in Stream::PutMaxHex64Raphael Isemann2018-08-011-3/+3
| | | | | | | | | | | | Reviewers: labath Reviewed By: labath Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D50025 llvm-svn: 338591
* Remove Stream::UnitTestRaphael Isemann2018-07-311-45/+0
| | | | | | | | | | | | | | Summary: No one is using this method, and it also doesn't really make a lot of sense to have it around. Reviewers: davide Reviewed By: davide Subscribers: davide, lldb-commits Differential Revision: https://reviews.llvm.org/D50026 llvm-svn: 338345
* Narrow the CompletionRequest API to being append-only.Raphael Isemann2018-07-272-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently allow any completion handler to read and manipulate the list of matches we calculated so far. This leads to a few problems: Firstly, a completion handler's logic can now depend on previously calculated results by another handlers. No completion handler should have such an implicit dependency, but the current API makes it likely that this could happen (or already happens). Especially the fact that some completion handler deleted all previously calculated results can mess things up right now. Secondly, all completion handlers have knowledge about our internal data structures with this API. This makes refactoring this internal data structure much harder than it should be. Especially planned changes like the support of descriptions for completions are currently giant patches because we have to refactor every single completion handler. This patch narrows the contract the CompletionRequest has with the different handlers to: 1. A handler can suggest a completion. 2. A handler can ask how many suggestions we already have. Point 2 obviously means we still have a dependency left between the different handlers, but getting rid of this is too large to just append it to this patch. Otherwise this patch just completely hides the internal StringList to the different handlers. The CompletionRequest API now also ensures that the list of completions is unique and we don't suggest the same value multiple times to the user. This property has been so far only been ensured by the `Option` handler, but is now applied globally. This is part of this patch as the OptionHandler is no longer able to implement this functionality itself. Reviewers: jingham, davide, labath Reviewed By: davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D49322 llvm-svn: 338151
* Remove unused History classRaphael Isemann2018-07-242-25/+0
| | | | | | | | | | | | | | Summary: This class doesn't seem to be used anywhere, so we might as well remove the code. Reviewers: labath Reviewed By: labath Subscribers: labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D49755 llvm-svn: 337855
* Replaced more boilerplate code with CompletionRequest (NFC)Raphael Isemann2018-07-132-16/+54
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As suggested in D48796, this patch replaces even more internal calls that were using the old completion API style with a single CompletionRequest. In some cases we also pass an option vector/index, but as we don't always have this information, it currently is not part of the CompletionRequest class. The constructor of the CompletionRequest is now also more sensible. You only pass the user input, cursor position and your list of matches to the request and the rest will be inferred (using the same code we used before to calculate this). You also have to pass these match window parameters to it, even though they are unused right now. The patch shouldn't change any behavior. Reviewers: jingham Reviewed By: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48976 llvm-svn: 337031
* Adjust thread name column width depending on real name length.Tatyana Krasnukha2018-07-131-1/+5
| | | | | | Make 16-byte aligned field instead of truncating a name to 16 byte. llvm-svn: 336993
* Refactor parsing of option lists with a raw string suffix.Raphael Isemann2018-07-101-3/+73
| | | | | | | | | | | | | | | | | | | | | | Summary: A subset of the LLDB commands follows this command line interface style: <command name> [arguments] -- <string suffix> The parsing code for this interface has been so far been duplicated into the different command objects which makes it hard to maintain and reuse elsewhere. This patches improves the situation by adding a OptionsWithRaw class that centralizes the parsing logic and allows easier testing. The different commands now just call this class to extract the arguments and the raw suffix from the provided user input. Reviewers: jingham Reviewed By: jingham Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D49106 llvm-svn: 336723
* Refactoring for for the internal command line completion API (NFC)Raphael Isemann2018-07-022-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch refactors the internal completion API. It now takes (as far as possible) a single CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest contains a common superset of the different parameters as far as it makes sense. This includes the raw command line string and raw cursor position, which should make the `expr` command possible to implement (at least without hacks that reconstruct the command line from the args). This patch is not intended to change the observable behavior of lldb in any way. It's also as minimal as possible and doesn't attempt to fix all the problems the API has. Some Q&A: Q: Why is this not fixing all the problems in the completion API? A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future. The patch also doesn't really change the internal information flow in the API, so that hopefully saves us from ever having to revert and resubmit this humongous patch. Q: Can we merge all the copy-pasted code in the completion methods (like computing the current incomplete arg) into CompletionRequest class? A: Yes, but it's out of scope for this patch. Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern? A: I don't want to add a getter that returns a reference to the internal integer. So we have to use a temporary variable and the Getter/Setter instead. We don't throw exceptions from what I can tell, so the behavior doesn't change. Q: Why are we not owning the list of matches? A: Because that's how the previous API works. But that should be fixed too (in another patch). Q: Can we make the constructor simpler and compute some of the values from the plain command? A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory propagate the changes on the nested request back to the parent request if we don't want to change the behavior too much). Q: Can't we pass one const request object and then just return another result object instead of mixing them together in one in/out parameter? A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just a single request object. If we make all input parameters read-only, we have a clear separation between what is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters). Q: Can we throw out the 'match' variables that are not implemented according to the comment? A: We currently just forward them as in the old code to the different methods, even though I think they are really not used. We can easily remove and readd them once every single completion method just takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user. Reviewers: davide, jingham, labath Reviewed By: jingham Subscribers: mgorny, friss, lldb-commits Differential Revision: https://reviews.llvm.org/D48796 llvm-svn: 336146
* UUID: Add support for arbitrary-sized module IDsPavel Labath2018-06-291-77/+37
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The data structure is optimized for the case where the UUID size is <= 20 bytes (standard length emitted by the GNU linkers), but larger sizes are also possible. I've modified the string conversion function to support the new sizes as well. For standard UUIDs it maintains the traditional formatting (4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and for longer UUIDs it will just repeat the last 6-byte block as long as necessary. I've also modified ObjectFileELF to take advantage of the new UUIDs and avoid manually padding the UUID to 16 bytes. While there, I also made sure the computed UUID does not depend on host endianness. Reviewers: clayborg, lemo, sas, davide, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D48633 llvm-svn: 335963
* Represent invalid UUIDs as UUIDs with length zeroPavel Labath2018-06-262-74/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we used an all-zero UUID for that). This meant that some valid build-ids could not be represented (it's possible however unlikely that a checksum of some file would be zero) and complicated adding support for variable length build-ids (should a 16-byte empty UUID compare equal to a 20-byte empty UUID?). This patch resolves these issues by introducing a canonical representation for an invalid UUID. The slight complication here is that some clients (MachO) actually use the all-zero notation to mean "no UUID has been set". To keep this use case working (while making it very explicit about which construction semantices are wanted), replaced the UUID constructors and the SetBytes functions with named factory methods. - "fromData" creates a UUID from the given data, and it treats all bytes equally. - "fromOptionalData" first checks the data contents - if all bytes are zero, it treats this as an invalid/empty UUID. Reviewers: clayborg, sas, lemo, davide, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D48479 llvm-svn: 335612
* [LLDB] Select helper sign comparison fixDavid Carlier2018-06-251-2/+2
| | | | | | | | | | | | The constant could be unsigned thus explicit cast to silent compilation warnings Reviewers: aprantl Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D48540 llvm-svn: 335489
* Revert "[FileSpec] Always normalize"Jonas Devlieghere2018-06-251-6/+104
| | | | | | | | This reverts r335432 because remove_dots() is expensive and measuring its impact showed an observable performance regression (https://reviews.llvm.org/D45977#1078510). llvm-svn: 335448
* [FileSpec] Always normalizeJonas Devlieghere2018-06-241-104/+6
| | | | | | | | Removing redundant components from the path seems pretty harmless. Rather than checking whether this is necessary and then actually doing so, always invoke remove_dots to start with a normalized path. llvm-svn: 335432
* [FileSpec] Refactor append and prepend implemenetations. NFCJonas Devlieghere2018-06-241-94/+20
| | | | | | | | Replaces custom implementations of append and prepend with calls to llvm's path library. This is part of a series of patches (started in D48084) to delegate common operations to llvm::sys::path. llvm-svn: 335430
* Remove UUID::SetFromCStringPavel Labath2018-06-211-9/+1
| | | | | | Replace uses with SetFromStringRef. NFC. llvm-svn: 335246
* Modernize UUID classPavel Labath2018-06-211-9/+7
| | | | | | | | | | | Instead of a separate GetBytes + GetByteSize methods I introduce a single GetBytes method returning an ArrayRef. This is NFC cleanup now, but it should make handling arbitrarily-sized UUIDs cleaner, should we choose to go that way. I also took the opportunity to add some unit tests for this class. llvm-svn: 335244
* Use llvm::VersionTuple instead of manual version marshallingPavel Labath2018-06-181-23/+0
| | | | | | | | | | | | | | | | | | Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
* [FileSpec] Make style argument mandatory for SetFile. NFCJonas Devlieghere2018-06-131-6/+9
| | | | | | | | | | | | | | | | SetFile has an optional style argument which defaulted to the native style. This patch makes that argument mandatory so clients of the FileSpec class are forced to think about the correct syntax. At the same time this introduces a (protected) convenience method to update the file from within the FileSpec class that keeps the current style. These two changes together prevent a potential pitfall where the style might be forgotten, leading to the path being updated and the style unintentionally being changed to the host style. llvm-svn: 334663
* [FileSpec] Simplify getting extension and stem.Jonas Devlieghere2018-06-131-8/+3
| | | | | | | As noted by Pavel on lldb-commits, we don't need the temp path, we can just pass the filename directly into extension() and path(). llvm-svn: 334618
* [FileSpec] Delegate common operations to llvm::sys::pathJonas Devlieghere2018-06-131-64/+45
| | | | | | | | | | | | | | | With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path helpers. This means we only have to maintain a single implementation and at the same time can benefit from the efforts made by the rest of the LLVM community. This is part one of a set of patches. There was no obvious way to split this so I just worked from top to bottom. Differential revision: https://reviews.llvm.org/D48084 llvm-svn: 334615
* [FileSpec] Re-implmenet removeLastPathComponentJonas Devlieghere2018-05-301-29/+8
| | | | | | | | | | | | | | | | | | | | | When reading DBGSourcePathRemapping from a dSYM, we remove the last two path components to make the source lookup more general. However, when dealing with a relative path that has less than 2 components, we ended up with an invalid (empty) FileSpec. This patch changes the behavior of removeLastPathComponent to remove the last path component, if possible. It does this by checking whether a parent path exists, and if so using that as the new path. We rely entirely on LLVM's path implementation to do the heavy lifting. We now also return a boolean which indicates whether the operator was successful or not. Differential revision: https://reviews.llvm.org/D47495 rdar://37791687 llvm-svn: 333540
* Typo fixes.Bruce Mitchener2018-05-291-2/+2
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* Fix PathMappingList for relative and empty paths after recent FileSpec ↵Greg Clayton2018-05-211-25/+29
| | | | | | | | | | | | | | | | | | normalization changes PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those. Changes include: Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason. Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code. Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other. Added tests for absolute, relative and empty paths. Differential Revision: https://reviews.llvm.org/D47021 llvm-svn: 332842
* FileSpec objects that resolve to "." should have "." in m_filename and ↵Greg Clayton2018-05-171-0/+8
| | | | | | | | | | | | m_directory empty. After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "". This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename. Differential Revision: https://reviews.llvm.org/D46783 llvm-svn: 332618
* FileSpec: Remove PathSyntax enum and use llvm version insteadPavel Labath2018-05-141-62/+45
| | | | | | | | | | | | | | | | | | | | Summary: The llvm version of the enum has the same enumerators, with stlightly different names, so this is mostly just a search&replace exercise. One concrete benefit of this is that we can remove the function for converting between the two enums. To avoid typing llvm::sys::path::Style::windows everywhere I import the enum into the FileSpec class, so it can be referenced as FileSpec::Style::windows. Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46753 llvm-svn: 332247
* Remove custom path manipulation functions from FileSpecPavel Labath2018-05-111-85/+5
| | | | | | | | | | | | | | | | | | | | Summary: now that llvm supports host-agnostic path manipulation functions (and most of their kinks have been ironed out), we can remove our copies of the path parsing functions in favour of the llvm ones. This should be NFC except for the slight difference in handling of the "//" path, which is now normalized to "/" (this only applies to the literal "//" path; "//net" and friends still get to keep the two slashes). Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46687 llvm-svn: 332088
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-021-21/+22
| | | | | | | | | | | | | | This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments. This patch also reflows the paragraphs in all doxygen comments. See also https://reviews.llvm.org/D46290. Differential Revision: https://reviews.llvm.org/D46321 llvm-svn: 331373
* Log to the process channel, not target twice.Jason Molenda2018-05-011-1/+1
| | | | llvm-svn: 331239
* Add logging when ArchSpec::SetArchitecture is given a cputype andJason Molenda2018-05-011-0/+5
| | | | | | | | cpusubtype that don't map to any known core definition. <rdar://problem/39779398> llvm-svn: 331236
* Reflow paragraphs in comments.Adrian Prantl2018-04-3020-465/+402
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Fixup r331049 (FileSpec auto-normalization)Pavel Labath2018-04-301-10/+4
| | | | | | | | | | | | | | | | | | A typo in the patch (using syntax instead of m_syntax) resulted in the normalization not working properly for windows filespecs when the syntax was passed as host-native. This did not affect the unit tests, as all of those pass an explicity syntax, but failed gloriously when running the full test suite. I also fix an expectation in an lldb-mi test, which was now failing because it was expecting a path to be echoed verbatim, but we were now normalizing it. As a drive-by, this also fixes the default-in-fully-covered-switch warning and removes an unused argument from the NeedsNormalization function. llvm-svn: 331172
* Fix build bots after r331049 broke them.Greg Clayton2018-04-271-10/+10
| | | | llvm-svn: 331082
* Always normalize FileSpec paths.Greg Clayton2018-04-271-106/+130
| | | | | | | | Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
* Move Args.cpp from Interpreter to UtilityPavel Labath2018-04-172-0/+686
| | | | | | | | | | | | | | | | | | | | | Summary: The Args class is used in plenty of places besides the command interpreter (e.g., anything requiring an argc+argv combo, such as when launching a process), so it needs to be in a lower layer. Now that the class has no external dependencies, it can be moved down to the Utility module. This removes the last (direct) dependency from the Host module to Interpreter, so I remove the Interpreter module from Host's dependency list. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D45480 llvm-svn: 330200
* s/LLVM_ON_WIN32/_WIN32/, lldbNico Weber2018-04-103-6/+4
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 329697
* Move StringExtractorGDBRemote.h to the include folderPavel Labath2018-03-202-205/+1
| | | | | | | | While trying to use this header I noticed that it is not in the include folder. Move it to there and update all #includes to reference that file correctly. llvm-svn: 327996
* Re-land: "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h. This change is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its default seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching and is used by the DWARF accelerator tables. Because some test were implicitly relying on the hash order, I've reverted to using zero as a seed for the following two files: lld/include/lld/Core/SymbolTable.h llvm/lib/Support/StringMap.cpp Differential revision: https://reviews.llvm.org/D43615 llvm-svn: 326091
* Revert "[Support] Replace HashString with djbHash."Jonas Devlieghere2018-02-261-2/+2
| | | | | | | | | | | | | It looks like some of our tests depend on the ordering of hashed values. I'm reverting my changes while I try to reproduce and fix this locally. Failing builds: lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388 lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743 lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607 llvm-svn: 326082
* [Support] Replace HashString with djbHash.Jonas Devlieghere2018-02-261-2/+2
| | | | | | | | | | | | | | | This removes the HashString function from StringExtraces and replaces its uses with calls to djbHash from DJB.h This is *almost* NFC. While the algorithm is identical, the djbHash implementation in StringExtras used 0 as its seed while the implementation in DJB uses 5381. The latter has been shown to result in less collisions and improved avalanching. https://reviews.llvm.org/D43615 (cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c) llvm-svn: 326081
* Remove ObjectFile usage from HostLinux::GetProcessInfoPavel Labath2018-01-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ObjectFile class was used to determine the architecture of a running process by inspecting it's main executable. There were two issues with this: - it's in the wrong layer - the call can be very expensive (it can end up computing the crc of the whole file). Since the process is running on the host, ideally we would be able to just query the data straight from the OS like darwin does, but there doesn't seem to be a reasonable way to do that. So, this fixes the layering issue by using the llvm object library to inspect the file. Since we know the process is already running on the host, we just need to peek at a few bytes of the elf header to determine whether it's 32- or 64-bit (which should make this faster as well). Pretty much the same logic was implemented in NativeProcessProtocol::ResolveProcessArchitecture, so I delete this logic and replace calls with GetProcessInfo. Reviewers: eugene, krytarowski Subscribers: mgorny, hintonda, lldb-commits Differential Revision: https://reviews.llvm.org/D42488 llvm-svn: 323637
* Add SysV Abi for PPC64lePavel Labath2018-01-221-0/+127
| | | | | | | | | | | | | | | | | Summary: This patch implements the ABI Plugin for PPC64le. It was based on the ABI for PPC64. It also enables LLDB to evaluate expressions using JIT. Reviewers: labath, clayborg, jhibbits, davide Reviewed By: labath, clayborg, jhibbits, davide Subscribers: davide, JDevlieghere, chmeee, emaste, jhibbits, hfinkel, lldb-commits, nemanjai, luporl, lbianc, mgorny, anajuliapc, kbarton Differential Revision: https://reviews.llvm.org/D41702 Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br> llvm-svn: 323100
* Add Utility/Environment class for handling... environmentsPavel Labath2018-01-102-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was some confusion in the code about how to represent process environment. Most of the code (ab)used the Args class for this purpose, but some of it used a more basic StringList class instead. In either case, the fact that the underlying abstraction did not provide primitive operations for the typical environment operations meant that even a simple operation like checking for an environment variable value was several lines of code. This patch adds a separate Environment class, which is essentialy a llvm::StringMap<std::string> in disguise. To standard StringMap functionality, it adds a couple of new functions, which are specific to the environment use case: - (most important) envp conversion for passing into execve() and likes. Instead of trying to maintain a constantly up-to-date envp view, it provides a function which creates a envp view on demand, with the expectation that this will be called as the very last thing before handing the value to the system function. - insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value) pair and inserts it into the environment map. - compose(value_type KeyValue) - takes a map entry and converts in back into "KEY=VALUE" representation. With this interface most of the environment-manipulating code becomes one-liners. The only tricky part was maintaining compatibility in SBLaunchInfo, which expects that the environment entries are accessible by index and that the returned const char* is backed by the launch info object (random access into maps is hard and the map stores the entry in a deconstructed form, so we cannot just return a .c_str() value). To solve this, I have the SBLaunchInfo convert the environment into the "envp" form, and use it to answer the environment queries. Extra code is added to make sure the envp version is always in sync. (This also improves the layering situation as Args was in the Interpreter module whereas Environment is in Utility.) Reviewers: zturner, davide, jingham, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41359 llvm-svn: 322174
* [ArchSpec] Don't consider Unknown MachO64 as invalid.Davide Italiano2018-01-051-1/+6
| | | | | | | | Even without a proper arch we can access line tables, etc.. <rdar://problem/35778442> llvm-svn: 321856
* Make sure DataBufferLLVM contents are writablePavel Labath2017-12-211-15/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that ability before, but with the introduction of DataBufferLLVM, we have lost it, as the underlying llvm class (MemoryBuffer) only supports read-only mappings. This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer class as a back-end, as this one guarantees to return a writable buffer. This removes the need for the "Private" flag to the DataBufferLLVM creation functions, as it was really used to mean "writable". The LLVM function also does not have the NullTerminate flag, so I've modified our clients to not require this feature and removed that flag as well. Reviewers: zturner, clayborg, jingham Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D40079 llvm-svn: 321255
* [DataEncoder] Replace buggy versions of write functions.Davide Italiano2017-12-131-36/+8
| | | | | | | | | This fixes a previously introduced thinko, now that I have a better idea of what's going on :) <rdar://problem/35941757> llvm-svn: 320540
* Add an #include to appease an older clang, NFCVedant Kumar2017-12-121-0/+1
| | | | | | | Add in a missing #include that AppleClang-900 complains about when building with -DLLVM_ENABLE_MODULES. llvm-svn: 320522
OpenPOWER on IntegriCloud