summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/UUID.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move UUID from Core -> Utility.Zachary Turner2017-03-041-224/+0
| | | | llvm-svn: 296941
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Convert UriParser to use StringRef.Zachary Turner2016-11-171-2/+4
| | | | llvm-svn: 287190
* Convert AutoComplete related code to StringRef.Zachary Turner2016-11-171-34/+33
| | | | | | Differential Revision: https://reviews.llvm.org/D26721 llvm-svn: 287188
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-231/+172
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Add Utility/ModuleCache class and integrate it with PlatformGDBRemoteServer ↵Oleksiy Vyalov2015-03-101-0/+3
| | | | | | | | - in order to allow modules caching from remote targets. http://reviews.llvm.org/D8037 llvm-svn: 231734
* Added a way to extract the module specifications from a file. A module ↵Greg Clayton2013-07-081-15/+24
| | | | | | | | | | | | | specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files). There are two new classes: lldb::SBModuleSpec lldb::SBModuleSpecList The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList. llvm-svn: 185877
* Split symbol support for ELF and Linux.Michael Sartain2013-07-011-5/+11
| | | | llvm-svn: 185366
* ObjectFileELF::GetModuleSpecifications on Linux should work now.Michael Sartain2013-05-231-22/+52
| | | | | | | Which means "platform process list" should work and list the architecture. We are now parsing the elf build-id if it exists, which should allow us to load stripped symbols (looking at that next). llvm-svn: 182610
* Remove the UUID::GetAsCString() method which required a buffer to save the Jason Molenda2013-05-031-6/+12
| | | | | | | UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
* <rdar://problem/13069948>Greg Clayton2013-01-251-1/+1
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* Wrapped up the work I am going to do for now for the "add-dsym" or "target ↵Greg Clayton2012-09-271-31/+42
| | | | | | | | | | | | | | | | | | | | symfile add" command. We can now do: Specify a path to a debug symbols file: (lldb) add-dsym <path-to-dsym> Go and download the dSYM file for the "libunc.dylib" module in your target: (lldb) add-dsym --shlib libunc.dylib Go and download the dSYM given a UUID: (lldb) add-dsym --uuid <UUID> Go and download the dSYM file for the current frame: (lldb) add-dsym --frame llvm-svn: 164806
* Added the ability to download a symboled executable and symbol file given a ↵Greg Clayton2012-09-271-3/+6
| | | | | | UUID. llvm-svn: 164753
* Header patch, virtual dtor patch and missed UUID patch from Kirk Beitz.Greg Clayton2011-02-051-1/+1
| | | | llvm-svn: 124931
* Remove bzero use and replace with memset (patch from Kirk Beitz).Greg Clayton2011-02-041-4/+4
| | | | llvm-svn: 124897
* Applied a fix to qualify "UUID" with the lldb_private namespace to fixGreg Clayton2011-02-041-13/+13
| | | | | | build issues on MinGW. llvm-svn: 124888
* Remove unused uuid_t constructor for lldb_private::UUID.Eli Friedman2010-06-101-8/+0
| | | | llvm-svn: 105780
* For header includes we are currently trying to adopt some aspects of the Greg Clayton2010-06-091-3/+4
| | | | | | | | | | | | Google C++ coding guidelines where includes are done as: 1 - the header file for the current source file 2 - C includes 3 - C++ includes 4 - external project includes 5 - current project includes llvm-svn: 105748
* Add missing includes.Eli Friedman2010-06-091-0/+3
| | | | llvm-svn: 105712
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+218
llvm-svn: 105619
OpenPOWER on IntegriCloud