summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* RichManglingContext: Make m_ipd_str_len a local variable and simplify ↵Stefan Granitz2018-08-102-29/+24
| | | | | | processIPDStrResult + polishing in test and Mangled llvm-svn: 339440
* Use rich mangling information in Symtab::InitNameIndexes()Stefan Granitz2018-08-083-45/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I set up a new review, because not all the code I touched was marked as a change in old one anymore. In preparation for this review, there were two earlier ones: * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function Primary goals for this patch are: (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index. (2) Provide a uniform interface. (3) Improve indexing performance. The central implementation in this patch is our new function for explicit demangling: ``` const RichManglingInfo * Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *) ``` It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are: * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`). * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing. The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`. Future potential: * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.) * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages. One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess). First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think. Reviewers: labath, jingham, JDevlieghere, erik.pilkington Subscribers: zturner, clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50071 llvm-svn: 339291
* Misc module/dwarf logging improvementsLeonard Mosescu2018-08-071-2/+6
| | | | | | | | | | | | | | This change improves the logging for the lldb.module category to note a few interesting cases: 1. Local object file found, but specs not matching 2. Local object file not found, using a placeholder module The handling and logging for the cases wehre we fail to load compressed dwarf symbols is also improved. Differential Revision: https://reviews.llvm.org/D50274 llvm-svn: 339161
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-0719-3903/+28
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Fix Mangled::Compare()Stefan Granitz2018-08-061-1/+1
| | | | llvm-svn: 339015
* Add ConstString::IsNull() to tell between null vs. empty strings and fix ↵Stefan Granitz2018-08-061-2/+2
| | | | | | | | | | | | | | usage in Mangled::GetDemangledName() Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangled::GetDemangledName() was incorrect. What it actually wants is a check for null-string. Split this off of D50071 and added a test to clarify usage. Reviewers: labath, jingham Subscribers: erik.pilkington, lldb-commits Differential Revision: https://reviews.llvm.org/D50327 llvm-svn: 339014
* Change ConstString::SetCStringWithMangledCounterpart to use StringRefPavel Labath2018-08-061-1/+1
| | | | | | | This should simplify the upcoming demangling patch (D50071). While I was in there, I also added a quick test for the function. llvm-svn: 338995
* Add byte counting mechanism to LLDB's Stream class.Raphael Isemann2018-08-022-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDB] Added syntax highlighting supportRaphael Isemann2018-08-024-4/+119
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed to use colors), printed source code is annotated with the ANSI color escape sequences. So far we have only one highlighter which is based on Clang and is responsible for all languages that are supported by Clang. It essentially just runs the raw lexer over the input and then surrounds the specific tokens with the configured escape sequences. Reviewers: zturner, davide Reviewed By: davide Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D49334 llvm-svn: 338662
* Narrow the CompletionRequest API to being append-only.Raphael Isemann2018-07-272-11/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use LLVM's new ItaniumPartialDemangler in LLDBStefan Granitz2018-07-251-29/+16
| | | | | | | | | | | | | | | Summary: Replace the existing combination of FastDemangle and the fallback to llvm::itaniumDemangle() with LLVM's new ItaniumPartialDemangler. It slightly reduces complexity and slightly improves performance, but doesn't introduce conceptual changes. This patch is preparing for more fundamental improvements on LLDB's demangling approach. Reviewers: friss, jingham, erik.pilkington, labath, clayborg, mgorny, davide, JDevlieghere Reviewed By: JDevlieghere Subscribers: teemperor, JDevlieghere, labath, clayborg, davide, lldb-commits, mgorny, erik.pilkington Differential Revision: https://reviews.llvm.org/D49612 llvm-svn: 337931
* Move dumping code out of RegisterValue classPavel Labath2018-07-245-65/+85
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The dump function was the only part of this class which depended on high-level functionality. This was due to the DumpDataExtractor function, which uses info from a running target to control dump format (although, RegisterValue doesn't really use the high-level part of DumpDataExtractor). This patch follows the same approach done for the DataExtractor class, and extracts the dumping code into a separate function/file. This file can stay in the higher level code, while the RegisterValue class and anything that does not depend in dumping can stay go to lower layers. The XCode project will need to be updated after this patch. Reviewers: zturner, jingham, clayborg Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D48351 llvm-svn: 337832
* Reimplement EventDataBytes::Dump to avoid DumpDataExtractorPavel Labath2018-07-241-9/+7
| | | | | | This is the only external non-trivial dependency of the Event classes. llvm-svn: 337819
* Fix the libcxx set, multiset, vector and bitset formatters to work on ↵Jim Ingham2018-07-131-1/+13
| | | | | | | | | | | | | | | | references. The synthetic child providers for these classes had a type expression that matched pointers & references to the type, but the Front End only worked on the actual object. I fixed this by adding a way for the Synthetic Child FrontEnd provider to request dereference, and then had these formatters use that mode. <rdar://problem/40849836> Differential Revision: https://reviews.llvm.org/D49279 llvm-svn: 337035
* Replaced more boilerplate code with CompletionRequest (NFC)Raphael Isemann2018-07-132-27/+22
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add abbreviated name for Debugger::EventHandlerThread.Tatyana Krasnukha2018-07-131-5/+8
| | | | | | On OS's where thread names are limited to 16 bytes, the full name was truncated to not very meaningful "r.event-handler". llvm-svn: 336991
* [IRInterpreter] Fix misevaluation of interpretation expressions with `urem`.Davide Italiano2018-07-121-5/+5
| | | | | | | | | | | | | | | | Scalar::MakeUnsigned was implemented incorrectly so it didn't really change the sign of the type (leaving signed types signed). This showed up as a misevaluation when IR-interpreting urem but it's likely to arise in other contexts. This commit fixes the definition, and adds a test to make sure this won't regress in future (hopefully). Fixes rdar://problem/42038760 and LLVM PR38076 Differential Revision: https://reviews.llvm.org/D49155 llvm-svn: 336872
* Change AddressClass type from 'enum' to 'enum class'.Tatyana Krasnukha2018-06-262-6/+6
| | | | | | If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
* ResolveAddress: check returned value of resolving functions.Tatyana Krasnukha2018-06-221-7/+8
| | | | llvm-svn: 335341
* Scalar: Use llvm integer conversion functionsPavel Labath2018-06-191-10/+6
| | | | | | | | | | StringConvert was the only non-Utility dependency of this class. Getting rid of it means it will be easy to move this class to a lower layer. While I was in there, I also added a couple of unit tests for the Scalar string conversion function. llvm-svn: 335060
* Replace HostInfo::GetLLDBPath with specific functionsPavel Labath2018-06-192-6/+4
| | | | | | | | | | | | | | | | | | | | | Summary: Instead of a function taking an enum value determining which path to return, we now have a suite of functions, each returning a single path kind. This makes it easy to move the python-path function into a specific plugin in a follow-up commit. All the users of GetLLDBPath were converted to call specific functions instead. Most of them were hard-coding the enum value anyway, so this conversion was simple. The only exception was SBHostOS, which I've changed to use a switch on the incoming enum value. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48272 llvm-svn: 335052
* Use llvm::VersionTuple instead of manual version marshallingPavel Labath2018-06-181-10/+4
| | | | | | | | | | | | | | | | | | 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] Delegate common operations to llvm::sys::pathJonas Devlieghere2018-06-131-2/+2
| | | | | | | | | | | | | | | 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
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-2/+2
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* Fix Module::FindTypes to return the correct number of matches.Frederic Riss2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | In r331719, I changed Module::FindTypes not to limit the amount of types returned by the Symbol provider, because we want all possible matches to be able to filter them. In one code path, the filtering was applied to the TypeList without changing the number of types that gets returned. This is turn could cause consumers to access beyond the end of the TypeList. This patch fixes this case and also adds an assertion to TypeList::GetTypeAtIndex to catch those obvious programming mistakes. Triggering the condition in which we performed the incorrect access was not easy. It happened a lot in mixed Swift/ObjectiveC code, but I was able to trigger it in pure Objective C++ although in a contrieved way. rdar://problem/40254997 llvm-svn: 333786
* Add .debug_names section glue codePavel Labath2018-06-011-0/+2
| | | | llvm-svn: 333743
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-312-10/+9
| | | | | | | | | | | | | | | | | | | Summary: As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317, FindGlobalVariables does not properly handle the case where append=false. As this doesn't seem to be used in the tree, this patch removes the parameter entirely. Reviewers: clayborg, jingham, labath Reviewed By: clayborg Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere Differential Revision: https://reviews.llvm.org/D46885 Patch by Tom Tromey <ttromey@mozilla.com>. llvm-svn: 333639
* Typo fixes.Bruce Mitchener2018-05-292-2/+2
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* Forward declare DumpValueObjectOptions in ValueObject.hRaphael Isemann2018-05-261-0/+1
| | | | | | | | | | | | Summary: This resolves unnecessary the header dependency from Core to DataFormatters. Patch is necessary for the introduction of C++ modules to the LLDB build system. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D47409 llvm-svn: 333342
* Break dependency from Core to ObjectFileJIT.Zachary Turner2018-05-232-22/+0
| | | | | | | | | | | | | | | | | | The only reason this was here was so that Module could have a function called CreateJITModule which created things in a special order. Instead of making this specific to creating JIT modules, I converted this into a template function that can create a module for any type of object file plugin and just forwards arguments through. Since the template is not instantiated in Core, the linker (and header file) dependency moves to the point where it is instantiated, which only happens in Expression. Conceptually, this location also makes more sense for a dependency on ObjectFileJIT. After all, we JIT expressions so it's no surprise that Expression needs to make use of ObjectFileJIT. Differential Revision: https://reviews.llvm.org/D47228 llvm-svn: 333143
* Add support to object files for accessing the .debug_types sectionGreg Clayton2018-05-081-0/+2
| | | | | | | | In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch Differential Revision: https://reviews.llvm.org/D46529 llvm-svn: 331777
* Really test type lookup in TestCppTypeLookup.pyFrederic Riss2018-05-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ... and fix one bug found this way. Currently, the test works not because types are looked up correctly, but because by injecting local variables we also materialize the types for Clang. If we disable the local variable injection, then one check fails. The reason of the failure is that FindTypes is run with max_matches==1 and this value is passed down to the symbol lookup functions. When the search is performed only on the basename (like it's the case for an entity defined in the root namespace), then the search will stop after having found one match on the basename. But that match might be in a namespace, we were really just looking up the basename in the accelerator tables. The solution is to not pass max_matches down, but to search without a limit and let RemoveMismatchedTypes do its job afterwards. Note the patch includes 2 hunks with the same change, but only the latter is tested. I couldn't find a way to create a testcase for the other branch of the if ('image lookup -t' allows me to get there, but it only ever returns one type anyway). Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46548 llvm-svn: 331719
* DWARFExpression: Convert file addresses to load addresses early on.Adrian Prantl2018-05-032-19/+21
| | | | | | | | | | | | | | | | | | This is a change that only affects Swift and is NFC for the language plugins on llvm.org. In Swift, we can have global variables with a location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression evaluator doesn't know how to apply a DW_OP_deref to a file address, but at the very end we convert the file address into a load address. This patch moves the file->load address conversion to right after the result of the DW_OP_addr is pushed onto the stack so that a subsequent DW_OP_deref (and potentially other operations) can be interpreted. rdar://problem/39767528 Differential revision: https://reviews.llvm.org/D46362 llvm-svn: 331492
* Revert "DWARFExpression: Convert file addresses to load addresses early on."Adrian Prantl2018-05-032-25/+17
| | | | | | This reverts commit 331462 while investigating bot breakage. llvm-svn: 331480
* Add back condition that was accidentally removed in r331462.Adrian Prantl2018-05-031-3/+5
| | | | | | This should make the bots much happier. llvm-svn: 331479
* DWARFExpression: Convert file addresses to load addresses early on.Adrian Prantl2018-05-032-19/+25
| | | | | | | | | | | | | | | | | | This is a change that only affects Swift and is NFC for the language plugins on llvm.org. In Swift, we can have global variables with a location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression evaluator doesn't know how to apply a DW_OP_deref to a file address, but at the very end we convert the file address into a load address. This patch moves the file->load address conversion to right after the result of the DW_OP_addr is pushed onto the stack so that a subsequent DW_OP_deref (and potentially other operations) can be interpreted. rdar://problem/39767528 Differential revision: https://reviews.llvm.org/D46362 llvm-svn: 331462
* Use conventional spelling of always-failing assert.Richard Smith2018-05-021-1/+1
| | | | | | Fixes -Wstring-conversion warning that was breaking -Werror builds. llvm-svn: 331406
* Use the UUID from the minidump's CodeView Record for placeholder modulesLeonard Mosescu2018-05-021-3/+14
| | | | | | | | | | | | | | | This change adds support for two types of Minidump CodeView records: PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html) This is by far the most common record type. ELF BuildID (found in Breakpad/Crashpad generated minidumps) This would set a proper UUID for placeholder modules, in turn enabling an accurate match with local module images. Differential Revision: https://reviews.llvm.org/D46292 llvm-svn: 331394
* Refactor GetNextPersistentVariableName into a non-virtual methodAdrian Prantl2018-04-301-1/+3
| | | | | | | | | | | | that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixes for return and error variables. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46088 llvm-svn: 331235
* Move the persistent variable counter into TargetAdrian Prantl2018-04-301-1/+1
| | | | | | | | | | | | | | | | | so it can be shared across multiple language plugins. In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang). This is NFC on llvm.org except for the Go plugin. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46083 llvm-svn: 331234
* Fix expression parser to not accept any type whose basename matches for a ↵Greg Clayton2018-04-301-2/+8
| | | | | | | | | | type that must exist at root level This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress. Differential Revision: https://reviews.llvm.org/D46128 llvm-svn: 331227
* Reflow paragraphs in comments.Adrian Prantl2018-04-3031-771/+655
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support reading section ".gnu_debugaltlink"Jan Kratochvil2018-04-291-4/+5
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
* Always normalize FileSpec paths.Greg Clayton2018-04-271-2/+2
| | | | | | | | 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
* Improve LLDB's handling of non-local minidumpsLeonard Mosescu2018-04-182-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, LLDB is creating a high-fidelity representation of a live process, including a list of modules and sections, with the associated memory address ranges. In order to build the module and section map LLDB tries to locate the local module image (object file) and will parse it. This does not work for postmortem debugging scenarios where the crash dump (minidump in this case) was captured on a different machine. Fortunately the minidump format encodes enough information about each module's memory range to allow us to create placeholder modules. This enables most LLDB functionality involving address-to-module translations. Also, we may want to completly disable the search for matching local object files if we load minidumps unless we can prove that the local image matches the one from the crash origin. (not part of this change, see: llvm.org/pr35193) Example: Identify the module from a stack frame PC: Before: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 frame #1: 0x00167c79 frame #2: 0x00167e6d frame #3: 0x7510336a frame #4: 0x77759882 frame #5: 0x77759855 After: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll Example: target modules list Before: error: the target has no associated executable images After: [ 0] C:\Windows\System32\MSVCP120D.dll [ 1] C:\Windows\SysWOW64\kernel32.dll [ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe [ 3] C:\Windows\System32\MSVCR120D.dll [ 4] C:\Windows\SysWOW64\KERNELBASE.dll [ 5] C:\Windows\SysWOW64\ntdll.dll NOTE: the minidump format also includes the debug info GUID, so we can fill-in the module UUID from it, but this part was excluded from this change to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or 20 bytes, while the CodeView GUIDs are normally 24 bytes) Differential Revision: https://reviews.llvm.org/D45700 llvm-svn: 330302
* Move Args.cpp from Interpreter to UtilityPavel Labath2018-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | 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-104-4/+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
* [Core] Grab-bag of improvements for Scalar.Davide Italiano2018-04-021-325/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
* [Core] Correctly handle float division in Scalar.Davide Italiano2018-03-271-1/+1
| | | | | | | | Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44693 llvm-svn: 328649
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-201-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
OpenPOWER on IntegriCloud