summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol/SymbolContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann2019-12-061-2/+2
|
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-041-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Remove FileSpec->CompileUnit inheritancePavel Labath2019-11-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
* [lldb] remove unsigned Stream::operator<< overloadsPavel Labath2019-11-261-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* lldb: Fix some -Wdeprecated-copy warningsPavel Labath2019-11-111-14/+0
| | | | | | | | gcc-9 started warning when a class defined a copy constructor without a copy assignment operator (or vice-versa). This fixes those warnings by deleting the other special member too (after verifying it doesn't do anything non-trivial).
* [Disassembler] Simplify a few methods (NFC)Jonas Devlieghere2019-09-041-76/+77
| | | | | | | Use early returns to highlight preconditions and make the code easier to follow. llvm-svn: 370994
* Fix LLDB_CONFIGURATION_DEBUG builds for the GetSymbolVendor removalPavel Labath2019-08-081-6/+2
| | | | | | fix one usage that is ifdefed-out in non-debug builds. llvm-svn: 368279
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* [NFC] Remove instances of unused ClangASTContext headerAlex Langford2019-07-191-1/+1
| | | | llvm-svn: 366519
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-241-1/+1
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* [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
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-151-5/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-14/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-1/+1
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-12/+12
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-3/+3
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [SymbolContext] Remove dead codeJonas Devlieghere2019-01-081-55/+12
| | | | | | Removes two methods from SymbolContextList that aren't referenced. llvm-svn: 350599
* [SymbolContext] Rewrite operator== to be more concise.Davide Italiano2018-12-291-6/+1
| | | | | | And probably, less error prone. NFCI. llvm-svn: 350146
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-7/+7
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-3/+3
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-47/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Expression parser] Look up module symbols before hunting globallySean Callanan2017-05-161-0/+157
| | | | | | | | | | | | | | | | | | | When it resolves symbol-only variables, the expression parser currently looks only in the global module list. It should prefer the current module. I've fixed that behavior by making it search the current module first, and only search globally if it finds nothing. I've also added a test case. After review, I moved the core of the lookup algorithm into SymbolContext for use by other code that needs it. Thanks to Greg Clayton and Pavel Labath for their help. Differential Revision: https://reviews.llvm.org/D33083 llvm-svn: 303223
* Rename Error -> Status.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* 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
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1319/+1081
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-0/+1
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* Adding an SBThread::StepInto that takes an end-line, also moved the code ↵Jim Ingham2016-02-131-0/+67
| | | | | | | | that figures out the address range for the step to SymbolContext. llvm-svn: 260772
* Rework breakpoint language filtering to use the symbol context's language.Dawn Perchik2015-12-161-0/+32
| | | | | | | | | | | | | | | | This patch reworks the breakpoint filter-by-language patch to use the symbol context instead of trying to guess the language solely from the symbol's name. This has the advantage that symbols compiled with debug info will have their actual language known. Symbols without debug info will still do the same "guess"ing because Symbol::GetLanguage() is implemented using Mangled::GuessLanguage(). The recognition of ObjC names was merged into Mangled::GuessLanguage. Reviewed by: jingham, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15326 llvm-svn: 255808
* Fix a crasher in SymbolContext::SortTypeList() where something that was ↵Greg Clayton2015-11-191-150/+92
| | | | | | | | iterating over a std::multimap was actually mutating the list. <rdar://problem/23605600> llvm-svn: 253618
* Fix potential null deref; after SymbolContextSpecifier::SymbolContextMatchesJason Molenda2015-10-281-1/+1
| | | | | | | has tested that sc.function is null, it would try to deref sc.function. It should be calling sc.symbol here. llvm-svn: 251583
* Testcase and fix for bug 24074Ravitheja Addepally2015-10-081-0/+168
| | | | | | | | | | | | | | | | | | | | 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-165/+0
| | | | | | 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-0/+165
| | | | | | | | | | | | | | | | 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
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-13/+4
| | | | | | | | | | | | | | | | | | | | 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
* Make stream::operator<< take "const" void *Pavel Labath2015-07-221-8/+8
| | | | | | | | | | | | | | Summary: This enables us to avoid casts to "void *" in some cases and avoids a couple of "casts off const qualifiers" warnings. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11388 llvm-svn: 242874
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-18/+18
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-4/+4
| | | | | | | | | | | | | | | 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
* Change the default disassembly format again. First attempt atJason Molenda2015-02-131-8/+31
| | | | | | | | | | | | | | | | changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
* Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron2015-01-151-3/+3
| | | | | | | | | | The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
* Modified LLDB to be able to lookup global variables by address.Greg Clayton2015-01-151-7/+55
| | | | | | | | | | | | This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address. This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name. The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups. <rdar://problem/18945678> llvm-svn: 226084
* Add a new disassembly-format specification so that the disassemblerJason Molenda2014-10-101-3/+9
| | | | | | | | | | | | | | | | | | | | | output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
* Switch NULL to C++11 nullptr in source/Symbol and source/UtilityEd Maste2014-04-201-48/+48
| | | | | | Patch by Robert Matusewicz llvm-svn: 206713
* "size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf ↵Greg Clayton2014-03-031-6/+6
| | | | | | | | style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-6/+6
| | | | llvm-svn: 202723
* Fix the format warnings.Sylvestre Ledru2013-10-311-6/+6
| | | | | | | | | | In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64. Fixes bug #17551. Patch by "/dev/humancontroller" llvm-svn: 193832
* Huge performance improvements when one breakpoint contains many locations.Greg Clayton2013-06-121-0/+47
| | | | | | | | | | 325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote. That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly. Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed. llvm-svn: 183820
* <rdar://problem/13217784>Greg Clayton2013-05-171-2/+28
| | | | | | "source list -n <func>" can now show more than one location that matches a function name. It will unique multiple of the same source locations so they don't get displayed. It also handles inline functions correctly. llvm-svn: 182067
OpenPOWER on IntegriCloud