summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/Module.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-6/+6
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Remove TimeValue usage from Core/ModulePavel Labath2016-11-091-5/+3
| | | | | | | | | | | | | | | | Summary: The only interesting part here is that TimePoint and TimeValue have different natural string representations, which affects "target modules list" output. It is now "2016-07-09 04:02:21.000000000", whereas previously in was "Sat Jul 9 04:02:21 2016". I wanted to check if we're OK with that. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26275 llvm-svn: 286349
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Remove TimeValue usage from FileSpec.hPavel Labath2016-11-011-22/+11
| | | | | | | | | | | | | | | | | | | | | Summary: The only usage there was in GetModificationTime(). I also took the opportunity to move this function from FileSpec to the FileSystem class - since we are using FileSpecs to also represent remote files for which we cannot (easily) retrieve modification time, it makes sense to make the decision to get the modification time more explicit. The new function returns a llvm::sys::TimePoint<>. To aid the transition from TimeValue, I have added a constructor to it which enables implicit conversion from a time_point. Reviewers: zturner, clayborg Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D25392 llvm-svn: 285702
* Change Module::RemapPath to use StringRef.Zachary Turner2016-09-231-1/+2
| | | | llvm-svn: 282277
* Make lldb::Regex use StringRef.Zachary Turner2016-09-211-1/+1
| | | | | | | | | | This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1675/+1438
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Delete Host/windows/win32.hZachary Turner2016-08-091-11/+11
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Centralize the way symbol and functions are looked up by making a ↵Greg Clayton2016-07-131-140/+189
| | | | | | | | | | | | | | Module::LookupInfo class that does all of the heavy lifting. Background: symbols and functions can be looked up by full mangled name and by basename. SymbolFile and ObjectFile are expected to be able to do the lookups based on full mangled name or by basename, so when the user types something that is incomplete, we must be able to look it up efficiently. For example the user types "a::b::c" as a symbol to set a breakpoint on, we will break this down into a 'lookup "c"' and then weed out N matches down to just the ones that match "a::b::c". Previously this was done manaully in many functions by calling Module::PrepareForFunctionNameLookup(...) and then doing the lookup and manually pruning the results down afterward with duplicated code. Now all places use Module::LookupInfo to do the work in one place. This allowed me to fix the name lookups to look for "func" with eFunctionNameTypeFull as the "name_type_mask", and correctly weed the results: "func", "func()", "func(int)", "a::func()", "b::func()", and "a::b::func()" down to just "func", "func()", "func(int)". Previously we would have set 6 breakpoints, now we correctly set just 3. This also extends to the expression parser when it looks up names for functions it needs to not get multiple results so we can call the correct function. <rdar://problem/24599697> llvm-svn: 275281
* Fix the use of lldb::eSymbolContextVariable.Greg Clayton2016-06-211-1/+2
| | | | | | | | | | In Address.cpp, we were asking for the lldb::eSymbolContextVariable to be resolved, yet we weren't using the variable. This code gets called when disassembling and can cause the manual creation of all global variables variables which can take minutes. Removing eSymbolContextVariable allows disassembly to not create these long pauses. In Module.cpp, if someone only specified the lldb::eSymbolContextVariable flag, we would not look into a module's debug info, now we will. <rdar://problem/26907449> llvm-svn: 273307
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-120/+111
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-111-65/+59
| | | | | | other minor fixes. llvm-svn: 263289
* Now that SymbolFileDWARF supports having types in completely separate .pcm ↵Greg Clayton2016-02-101-6/+10
| | | | | | | | | | | | | | file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument: llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. <rdar://problem/24581488> llvm-svn: 260434
* Set symbol types for function symbols loaded from PE/COFFAdrian McCarthy2016-01-261-8/+10
| | | | | | | | | | | | | | | | This fixes the regression of several tests on Windows after rL258621. The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over. The fix sets the type information for functions (and creates a TODO for other types). Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand. In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM. Differential Revision: http://reviews.llvm.org/D16563 llvm-svn: 258758
* [LLDB] Consider only valid symbols while resolving by addressMohit K. Bhakkad2016-01-231-1/+10
| | | | | | | | Reviewers: clayborg. Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits. Differential Revision: http://reviews.llvm.org/D16397 llvm-svn: 258621
* Moved the target specific ClangASTContext initialization over into ↵Greg Clayton2015-10-081-20/+1
| | | | | | | | ClangASTContext::CreateInstance. This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases. llvm-svn: 249747
* Testcase and fix for bug 24074Ravitheja Addepally2015-10-081-11/+17
| | | | | | | | | | | | | | | | | | | | Summary: In bug 24074, the type information is not shown correctly. This commit includes the following - -> Changes for displaying correct type based on current lexical scope for the command "image lookup -t" -> The corresponding testcase. -> This patch was reverted due to segfaults in FreeBSD and Mac, I fixed the problems for both now. Reviewers: emaste, granata.enrico, jingham, clayborg Differential Revision: http://reviews.llvm.org/D13290 llvm-svn: 249673
* Revert 248366 "Testcase and fix for bug 24074"Enrico Granata2015-09-231-17/+11
| | | | | | This commit introduced regressions in several test cases on FreeBSD and Mac OS X llvm-svn: 248421
* Testcase and fix for bug 24074Ravitheja Addepally2015-09-231-11/+17
| | | | | | | | | | | | | | | | Summary: In bug 24074, the type information is not shown correctly. This commit includes the following - -> Changes for displaying correct type based on current lexical scope for the command "image lookup -t" -> The corresponding testcase. Reviewers: jingham, ovyalov, spyffe, richard.mitton, clayborg Differential Revision: http://reviews.llvm.org/D12404 llvm-svn: 248366
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-171-65/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
* Add a TypeSystem for GoRyan Brown2015-09-141-1/+20
| | | | | | | | Add GoASTContext and DWARFASTParserGo to support go. Differential Revision: http://reviews.llvm.org/D12585 llvm-svn: 247629
* Fix TestLoadUnload.test_load_unload for android API > 21Tamas Berghammer2015-09-041-1/+2
| | | | | | | | | | | | * Change Module::MatchesModuleSpec to return true in case the file spec in the specified module spec matches with the platform file spec, but not with the local file spec * Change the module_resolver used when resolving a remote shared module to always set the platform file spec to the file spec requested Differential revision: http://reviews.llvm.org/D12601 llvm-svn: 246852
* Move more functionality from the LanguageRuntimes to the Languages.Jim Ingham2015-09-021-10/+10
| | | | llvm-svn: 246616
* Move things from the LanguageRuntime that obviously belong in the new ↵Jim Ingham2015-09-021-3/+4
| | | | | | Language plugin instead. llvm-svn: 246611
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-9/+9
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* Move all clang type system DWARF type parsing into ClangASTContext.cpp.Greg Clayton2015-08-141-0/+11
| | | | | | Another step towards isolating all language/AST specific code into the files to further abstract specific implementations of parsing types for a given language. llvm-svn: 245090
* Fix issues with separate symbolfile handlingTamas Berghammer2015-07-301-0/+3
| | | | | | Differential revision: http://reviews.llvm.org/D11595 llvm-svn: 243637
* Use double-checked locking to avoid locking the Module mutex if we don't ↵Greg Clayton2015-07-241-62/+74
| | | | | | | | need to. This avoid a deadlock we were seeing in Xcode. <rdar://problem/21512067> llvm-svn: 243180
* Add support for specifying a language to use when parsing breakpoints.Dawn Perchik2015-07-211-2/+12
| | | | | | | | | | | | | | | | | | | | Target and breakpoints options were added: breakpoint set --language lang --name func settings set target.language pascal These specify the Language to use when interpreting the breakpoint's expression (note: currently only implemented for breakpoints on identifiers). If the breakpoint language is not set, the target.language setting is used. This support is required by Pascal, for example, to set breakpoint at 'ns.foo' for function 'foo' in namespace 'ns'. Tests on the language were also added to Module::PrepareForFunctionNameLookup for efficiency. Reviewed by: clayborg Subscribers: jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D11119 llvm-svn: 242844
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-3/+2
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Make sure that "add-dsym" can't crash us when using it.Greg Clayton2015-03-311-8/+38
| | | | | | | | | | I am fixing this by: 1 - make sure we aren't trying to set the symbol file for a module to the same thing it already has and leaving it alone if it is the same 2 - keep all old symbol files around in the module in case there are any outstanding type references <rdar://problem/18029116> llvm-svn: 233757
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-1/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Remove Host::Backtrace in favor of llvm::sys::PrintStackTrace()Zachary Turner2015-03-061-1/+9
| | | | | | | | | | | | This removes Host::Backtrace from the codebase, and changes all call sites to use llvm::sys::PrintStackTrace(). This makes the functionality available for all platforms, and even for platforms which currently had a supported implementation of Host::Backtrace, this patch should enable richer information in stack traces, such as file and line number information, as well as giving it the ability to unwind through inlined functions. llvm-svn: 231511
* Don't #include ClangASTContext.h from Module.hZachary Turner2015-03-031-5/+6
| | | | | | | | | | | | This is part of a larger effort to reduce header file footprints. Combined, these patches reduce the build time of LLDB locally by over 30%. However, they touch many files and make many changes, so will be submitted in small incremental pieces. Reviewed By: Greg Clayton Differential Revision: http://reviews.llvm.org/D8022 llvm-svn: 231097
* Fix Bug 20400Chaoren Lin2015-02-261-1/+1
| | | | | | | | | | | | | | | | | | | Summary: http://llvm.org/bugs/show_bug.cgi?id=20400 The default triple of i686-pc-linux-gnu for 32 bit linux targets is compatible but not necessarily identical to the inferior binaries. Applying Azat Khuzhin's solution of using ArchSpec::IsCompatibleMatch() instead of ArchSpec::IsExactMatch() when comparing ObjectFile and Modules architecture. Reviewers: vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7897 llvm-svn: 230694
* Don't wait for the dynamic loader to set a module as a dynamic link editor, ↵Greg Clayton2015-02-051-3/+10
| | | | | | | | | | figure it out through the ObjectFile. Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups. <rdar://problem/19716267> llvm-svn: 228261
* If we say:Greg Clayton2015-01-281-1/+1
| | | | | | | | (lldb) b isEqual: We end up calling "breakpoint set --name "isEqual:" and it was not checking for selectors due to a logic error. llvm-svn: 227281
* Don't stomp the triple when loading a PECOFF target.Zachary Turner2015-01-221-3/+7
| | | | | | | | | | | | | | | | | | | | | When you create a target, it tries to look for the platform's list of supported architectures for a match. The match it finds can contain specific triples, like i386-pc-windows-msvc. Later, we overwrite this value with the most generic triple that can apply to any platform with COFF support, causing some of the fields of the triple to get overwritten. This patch changes the behavior to only merge in values from the COFF triple if the fields of the matching triple were unknown/unspecified to begin with. This fixes load address resolution on Windows, since it enables the DynamicLoaderWindows to be used instead of DynamicLoaderStatic. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D7120 llvm-svn: 226849
* Setting breakpoints with name mask eFunctionNameTypeBase was broken for ↵Jim Ingham2014-10-251-20/+11
| | | | | | | | straight C names by 220432. Get that working again. llvm-svn: 220602
* Fixed name lookups for names that contain "::" but aren't actually C++ ↵Greg Clayton2014-10-221-0/+2
| | | | | | | | | | | | qualified C++ names. To do this, I fixed the CPPLanguageRuntime::StripNamespacesFromVariableName() function to use a regular expression that correctly determines if the name passed to it is a qualfied C++ name like "a::b::c" or "b::c". The old version of this function was treating '__54-[NSUserScriptTask executeWithInterpreter:arguments::]_block_invoke' as a match with a basename of ']_block_invoke'. Also fixed a case in the by name lookup of functions where we wouldn't look for the full name if we actually tried to call CPPLanguageRuntime::StripNamespacesFromVariableName() and got an empty basename back. <rdar://problem/18527866> llvm-svn: 220432
* Add error report when Module::GetObjectFile() fails to find a plugin to open ↵Todd Fiala2014-09-051-0/+4
| | | | | | | | an object file. Change by Stephane Sezer. llvm-svn: 217251
* When adding a dSYM to an existing ObjectFile, we can have a situationJason Molenda2014-08-221-0/+11
| | | | | | | | | | | | | | | | | | with binaries in the dyld shared cache (esp on iOS) where the file address for the executable binary (maybe from memory, maybe from an expanded copy of the dyld shared cache) is different from the file address in the dSYM. In that case, ObjectFileMachO replaces the file addresses from the original binary with the dSYM file addresses (usually 0-based) -- lldb doesn't have a notion of two file addresses for a given module so they need to agree. There was a cache of file addresses over in the Symtab so I added a method to the Module and the objects within to clear any file address caches if they exist, and added an implementation in the Symtab module to do that. <rdar://problem/16929569> llvm-svn: 216258
* Don't search for module resources at all if the setting is set to "false". Greg Clayton2014-08-181-2/+3
| | | | llvm-svn: 215936
* In order for the debug script filename to be valid as a module name, LLDB ↵Enrico Granata2014-08-161-1/+2
| | | | | | does some textual replacements. However, if one were unaware of this, they might name their script using the 'untampered' file name and they would get no feedback about it. Add logic to LLDB to make sure we tell people about those changes if it turns out they might need to know. Fixes rdar://14310572 llvm-svn: 215798
* Update lldb to track recent Triple arm64 enum removal and collapse into aarch64.Todd Fiala2014-07-231-1/+1
| | | | | | | | | | | See the following llvm change for details: r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines AArch64: remove arm64 triple enumerator. This change fixes build breaks on Linux and MacOSX lldb. llvm-svn: 213755
* Start converting usages of off_t to other types.Zachary Turner2014-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
* Fix typos.Bruce Mitchener2014-07-011-6/+6
| | | | llvm-svn: 212132
* iOS simulator cleanup to make sure we use "*-apple-ios" for iOS simulator ↵Greg Clayton2014-05-291-8/+38
| | | | | | | | | | | | | | | | | | apps and binaries. Changes include: - ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands - ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK). - Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo - PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using: (lldb) platform select ios-simulator (lldb) platform process list - debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables - GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly <rdar://problem/17060217> llvm-svn: 209852
* Fixed the Module::Module(ModuleSpec) constructor to properly copy the file ↵Greg Clayton2014-05-291-2/+2
| | | | | | offset and object file mod time from the actual module specifications so we will always be able to directly load the image we care about when calling Module::GetObjectFile(). llvm-svn: 209833
OpenPOWER on IntegriCloud