summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "Fix IPv6 support on lldb-server platform"Alex Langford2019-05-181-1/+1
| | | | | | | | | | | This reverts commit c28f81797084b8416ff5be4f9e79000a9741ca6a. This reverts commit 7e79b64642486f510f7872174eb831df68d65b84. Looks like there is more work to be done on this patch. I've spoken to the author and for the time being we will revert to keep the buildbots green. llvm-svn: 361086
* [CommandInterpreter] Refactor SourceInitFileJonas Devlieghere2019-05-172-88/+113
| | | | | | | | | | | | | | | | | | | | | | I was looking at the current implementation of SourceInitFile and there were a few things that made this function hard to read: * The code to find the ~/.lldbinit file is duplicated across the cwd and non-cwd branch. * The ./.lldbinit is once computed by resolving .lldbinit and once by resolving ./.lldbinit. * It wasn't clear to me what happened when you're sourcing the .lldbinit file in the current working directory. Apparently we do nothing when we property to control that is set to warn (makes sense) and we don't care when the property is set to true (debatable). * There were at least two branches where the status of the CommandReturnObject were not set. This patch attempts to simplify that code. Differential revision: https://reviews.llvm.org/D61994 llvm-svn: 361080
* Fix IPv6 support on lldb-server platformAlex Langford2019-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a general fix for the ConnectionFileDescriptor class but my main motivation was to make lldb-server working with IPv6. The connect URI can use square brackets ([]) to wrap the interface part of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses this is a must since its ip can include colons and it will overlap with the port colon otherwise. The URIParser class parses the square brackets correctly but the ConnectionFileDescriptor doesn't generate them for IPv6 addresses making it impossible to connect to the gdb server when using this protocol. How to reproduce the issue: $ lldb-server p --server --listen [::1]:8080 ... $ lldb (lldb) platform select remote-macosx (lldb) platform connect connect://[::1]:8080 (lldb) platform process -p <pid> error: unable to launch a GDB server on 'computer' The server was actually launched we were just not able to connect to it. With this fix lldb will correctly connect. I fixed this by wrapping the ip portion with []. Differential Revision: https://reviews.llvm.org/D61833 Patch by António Afonso <antonio.afonso@gmail.com> llvm-svn: 361079
* [EditLine] Check string pointers before dereferencing them.Davide Italiano2019-05-171-2/+3
| | | | | | | | | Get*AtIndex() can return nullptr. This only happens in the swift REPL support, so it's hard to test upstream. <rdar://problem/50875178> llvm-svn: 361078
* [CommandInterpreter] Fix trailing blanks after `all` or [0-9]+ for btStella Stamenova2019-05-171-4/+4
| | | | | | The change that was committed for this used \\s to match spaces which does not work correctly on all platforms. Using [:space:] makes the test pass on both Linux and Windows llvm-svn: 361064
* minidump: Use MemoryList parsing code from llvmPavel Labath2019-05-173-42/+23
| | | | llvm-svn: 361010
* Make DWARFContext dwo-aware and port debug_info sections overPavel Labath2019-05-179-34/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The previous attempt and moving section handling over to DWARFContext (D59611) failed because it did not take into account the dwo sections correctly. All DWARFContexts (even those in SymbolFileDWARFDwo) used the main module for loading the sections, but in the dwo scenario some sections should come from the dwo file. This patch fixes that by making the DWARFContext aware of whether it a dwo context or a regular one. A dwo context gets two sections lists, and it knows where to look for a particular type of a section. This isn't fully consistent with how the llvm DWARFContext behaves, because that one leaves it up to the user to know whether it should ask for a dwo section or not. However, for the time being, it seems useful to have a single entity which knows how to peice together the debug info in dwo and non-dwo scenarios. The rough roadmap for the future is: - port over the rest of the sections to DWARFContext - find a way to get rid of SymbolFileDWARFDwo/Dwp/DwpDwo. This will likely involve adding the ability for the DWARFContext to spawn dwo sub-contexts, similarly to how it's done in llvm. - get rid of the special handling of the "dwo" contexts by making sure everything knows whether it should ask for the .dwo version of the section or not (similarly to how llvm's DWARFUnits do that) To demonstrate how the DWARFContext should behave in this new world, I port the debug_info section (which is debug_info.dwo in the dwo file) handling to DWARFContext. The rest of the sections will come in subsequent patches. Reviewers: aprantl, clayborg, JDevlieghere Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D62012 llvm-svn: 361000
* [CommandInterpreter] Accept blanks after `all` or [0-9]+ for bt.Davide Italiano2019-05-171-4/+4
| | | | | | | | | | | Previously "bt all " would've failed as the regex didn't match them. Over the shoulder review by Jonas Devlieghere. <rdar://problem/50824935> llvm-svn: 360966
* [Target] Stop linking against lldbPluginObjCLanguageAlex Langford2019-05-162-2/+1
| | | | llvm-svn: 360945
* Factor out switch statement into a helper function (NFC)Adrian Prantl2019-05-162-10/+22
| | | | | | This addresses post-commit review feedback for https://reviews.llvm.org/D62015. llvm-svn: 360930
* Make sure GetObjectDescription falls back to the Objective-C runtime.Adrian Prantl2019-05-161-27/+29
| | | | | | | | | | | | | This fixes an unintended regression introduced by https://reviews.llvm.org/D61451 by making sure the Objective-C runtime is also tried when the "correct" language runtime failed to return an object description. rdar://problem/50791055 Differential Revision: https://reviews.llvm.org/D62015 llvm-svn: 360929
* [IRExecutionUnit] Remove static_assertJonas Devlieghere2019-05-161-2/+0
| | | | | | This doesn't make sense on platforms other than 64 bit. llvm-svn: 360916
* DWARFContext: Return empty data extractors instead of null pointersPavel Labath2019-05-164-27/+23
| | | | | | | | | | | | | | | | | | | | | | | Summary: There are several reasons for doing this: - generally, there's no reason to differentiate between a section being absent and it being present, but empty - it matches more closely what llvm DWARF parser is doing (which also doesn't differentiate the two cases) - SymbolFileDWARF also doesn't differentiate the two cases, which makes porting the rest of sections easier - it fixes a bug in how the return-null-if-empty logic was implemented (it returned nullptr only the second time we tried to get the debug_aranges section), which meant that we hit an assert when trying to parse an empty-but-present section Reviewers: JDevlieghere, clayborg, aprantl Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D61942 llvm-svn: 360874
* DWARF: Add ability to reference debug info coming from multiple sectionsPavel Labath2019-05-1616-55/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4). The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway. This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61908 llvm-svn: 360872
* Simplify Triple::ppc64{,le} checks with Triple::isPPC64()Fangrui Song2019-05-165-25/+14
| | | | | | | | | | While here, update some ppc64le specific check to isPPC64(), if it applies to big-endian as well, in the hope that it will ease the support of big-endian if people are interested in this area. The big-endian variant is used by at least FreeBSD, Gentoo Linux, Adélie Linux, and Void Linux. llvm-svn: 360868
* Simplify ArchSpec::IsMIPS()Fangrui Song2019-05-1610-66/+15
| | | | llvm-svn: 360865
* Permit cross-CU referencesJan Kratochvil2019-05-1513-131/+110
| | | | | | | | | | | | | | So far dw_offset_t was global for the whole SymbolFileDWARF but with .debug_types the same dw_offset_t may mean two different things depending on its section (=CU). So references now return whole new referenced DWARFDIE instead of just dw_offset_t. This means that some functions have to now handle 16 bytes instead of 8 bytes but I do not see that anywhere performance critical. Differential Revision: https://reviews.llvm.org/D61502 llvm-svn: 360795
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-1513-104/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* [ASTImporter] Use llvm::Expected and Error in the importer APIGabor Marton2019-05-155-43/+106
| | | | | | | | | | | | | | | | | | | | | | Summary: This is the final phase of the refactoring towards using llvm::Expected and llvm::Error in the ASTImporter API. This involves the following: - remove old Import functions which returned with a pointer, - use the Import_New functions (which return with Err or Expected) everywhere and handle their return value - rename Import_New functions to Import This affects both Clang and LLDB. Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D61438 llvm-svn: 360760
* DWARF: s/CompileUnit/Unit/ in DWARFFormValuePavel Labath2019-05-155-59/+51
| | | | | | | | The class has been converted to use DWARFUnit, but a number of uses of the words compile unit remained. This removes all such references Get/SetCompileUnit becomes Get/SetUnit, and m_cu becomes m_unit. llvm-svn: 360754
* Replace assert with static_assert here applicable.Jonas Devlieghere2019-05-154-10/+11
| | | | | | | Replaces assert() with static_assert() if the condition is can be evaluated at compile time. llvm-svn: 360753
* Mark private unimplemented functions as deletedJonas Devlieghere2019-05-151-2/+2
| | | | | | | Applies modernize-use-equals-delete to the LLDB code base and removes the now redundant comments. llvm-svn: 360751
* [Target] Generalize some behavior in ThreadAlex Langford2019-05-152-13/+23
| | | | | | | | | | Summary: I don't think there's a good reason for this behavior to be considered ObjC-specific. We can generalize this. Differential Revision: https://reviews.llvm.org/D61776 llvm-svn: 360741
* DWARF/NFC: Centralize DIERef conversionsPavel Labath2019-05-143-40/+24
| | | | | | | | | | | | | apple and manual indexing code were creating a DIERef in a bunch of places. Though the code itself is not much, it is also easy to simplify by factoring out the DIERef creation. In HashedNameToDIE I create a conversion operator from DIEInfo to DIERef, and in ManualDWARFIndex I just create the DIERef in a global variable up-front. This also reduces the diff in follow-up patches which change how DIERefs are constructed. llvm-svn: 360669
* typedef enum -> enumFangrui Song2019-05-1411-63/+45
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654
* ARMDefines.h: fix -Wimplicit-fallthrough in -DLLVM_ENABLE_ASSERTIONS=OFF buildsFangrui Song2019-05-141-2/+3
| | | | | | | | Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D61844 llvm-svn: 360646
* Merge target and launch info environmentsJonas Devlieghere2019-05-131-1/+4
| | | | | | | | | | | Before this change we were overriding the launch info environment with the target environment. This meant that the environment variables passed to `process launch --environment <>` were lost. Instead of replacing the environment, we should merge them. Differential revision: https://reviews.llvm.org/D61864 llvm-svn: 360612
* Remove commented-out codeJonas Devlieghere2019-05-131-43/+0
| | | | llvm-svn: 360611
* [DataFormatters] FindLibCppStdFunctionCallableInfo() currently uses ↵Shafik Yaghmour2019-05-131-2/+2
| | | | | | | | FindFunctions() in order to find a lambdas operator()() but using FindSymbolsMatchingRegExAndType() is cheaper and if we also anchor the regex using ^ this adds some additional performance gains. Differential Revision: https://reviews.llvm.org/D61759 llvm-svn: 360599
* DWARF/DIERef: remove non-const operator<Pavel Labath2019-05-131-2/+0
| | | | | | It serves no purpose as one can always invoke the const version instead. llvm-svn: 360583
* Breakpad: Generate unwind plans from STACK CFI recordsPavel Labath2019-05-132-2/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the GetUnwindPlan interface (added in the previous patch) for SymbolFileBreakpad, and uses it to generate unwind plans from STACK CFI records in breakpad files. We first perform a light-weight parse of the breakpad in order to build up a map of regions covered by the unwind info so that we can later jump to the right record when we need to unwind a specific function. The actual parsing is relatively straight-forward, as the STACK CFI records are just another (text) form of the eh_frame unwind instructions, and the same goes for lldb's UnwindPlans. The newly-introduced PostfixExpression API is used to convert the breakpad postfix expressions into DWARF. The generated dwarf expressions are stored in a BumpPtrAllocator, as the UnwindPlan does not take ownership of the expression data it references (usually this is static data in an object file, so special ownership is needed). At this moment the generated unwind plans aren't used in the actual unwind machinery (only in the image show-unwind command), but that is coming in a separate patch. Reviewers: amccarth, clayborg, markmentovai Subscribers: aprantl, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D61733 llvm-svn: 360574
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-132-0/+19
| | | | | | | | | | | | | | | | | Summary: This patch implements missing case in PdbAstBuilder::CreateType for LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct methods. Reviewers: amccarth, aleksandr.urakov Reviewed By: amccarth Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy Differential Revision: https://reviews.llvm.org/D61128 llvm-svn: 360569
* [DWARF] Use sequential integers for the IDs of the SymbolFileDWOsPavel Labath2019-05-132-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of using the offset of the contained compile unit, we use it's ID. The goal of this change is two-fold: - free up space in the user_id_t representation to enable storing the debug-info-carrying section (debug_types/debug_info) without decreasing the amount of debug info we can address (as would be the case with D61503). - be a step towards supporting DWO files containing more than one unit (important for debug_types+dwo, but can also happen with regular dwo+lto). For this part to fully work we'd still need to add a way to lookup the SymbolFileDWO without going through GetCompileUnitAtIndex, but making sure things don't accidentally work because the SymbolFile ID is the same as compile unit offset is a step towards that. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mehdi_amini, dexonsmith, tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61783 llvm-svn: 360565
* Fix file names in file headers. NFCFangrui Song2019-05-1317-17/+17
| | | | llvm-svn: 360554
* [Breakpoint] Make breakpoint language agnosticAlex Langford2019-05-114-59/+68
| | | | | | | | | | | | | | | | | | | Summary: Breakpoint shouldn't need to depend on any specific details from a programming language. Currently the only language-specific detail it takes advantage of are the different qualified names an objective-c method name might have when adding a name lookup. This is reasonably generalizable. The current method name I introduced is "GetVariantMethodNames", which I'm not particularly tied to. If you have a better suggestion, please do let me know. Reviewers: JDevlieghere, jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D61746 llvm-svn: 360509
* Finish renaming CompileUnit -> UnitJan Kratochvil2019-05-1012-93/+85
| | | | | | | | | | | | | D42892 changed a lot of code to use superclass DWARFUnit instead of its subclass DWARFCompileUnit. Finish this change more thoroughly for any *CompileUnit* -> *Unit* names. Later patch will introduce DWARFTypeUnit which needs to be sometimes different from DWARFCompileUnit and it would be confusing without this renaming. Differential Revision: https://reviews.llvm.org/D61501 llvm-svn: 360443
* minidump: Don't eagerly resolve module paths read from the minidumpPavel Labath2019-05-101-1/+0
| | | | | | | | This can cause us to return paths to files on the local filesystem even if we don't end up using that file (for instance because the file is not a real module). llvm-svn: 360432
* Minidump: use ThreadList parsing code from llvm/ObjectPavel Labath2019-05-108-91/+36
| | | | llvm-svn: 360412
* FuncUnwinders: Add a new "SymbolFile" unwind planPavel Labath2019-05-104-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: some unwind formats are specific to a single symbol file and so it does not make sense for their parsing code live in the general Symbol library (as is the case with eh_frame for instance). This is the case for the unwind information in breakpad files, but the same will probably be true for PDB unwind info (once we are able to parse that). This patch adds the ability to fetch an unwind plan provided by a symbol file plugin, as discussed in the RFC at <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. I've kept the set of changes to a minimum, as there is no way to test them until we have a symbol file which implements this API -- that is comming in a follow-up patch, which will also implicitly test this change. The interesting part here is the introduction of the "RegisterInfoResolver" interface. The reason for this is that breakpad needs to be able to resolve register names (which are present as strings in the file) into register enums so that it can construct the unwind plan. This is normally done via the RegisterContext class, handing this over to the SymbolFile plugin would mean that it has full access to the debugged process, which is not something we want it to have. So instead, I create a facade, which only provides the ability to query register names, and hide the RegisterContext behind the facade. Also note that this only adds the ability to dump the unwind plan created by the symbol file plugin -- the plan is not used for unwinding yet -- this will be added in a third patch, which will add additional tests which makes sure the unwinding works as a whole. Reviewers: jasonmolenda, clayborg Subscribers: markmentovai, amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D61732 llvm-svn: 360409
* Revert "Disable the step over skipping calls feature since buildbots are not ↵Pavel Labath2019-05-101-2/+2
| | | | | | | | | | | | | | | | happy." While this fixed the windows bot failures, it also broke all other bots. Upon closer inspection, it turns out that the windows bots were "broken" because two tests were unexpectedly passing -- i.e., the original patch (r360375) actually improved our stepping support on windows. So instead, I remove the relevant XFAILs. This reverts commit r360397. llvm-svn: 360407
* Disable the step over skipping calls feature since buildbots are not happy.Greg Clayton2019-05-101-2/+2
| | | | llvm-svn: 360397
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-093-5/+10
| | | | | | | | | | calls and stepping into and them out of each one Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue. Differential Revision: https://reviews.llvm.org/D58678 llvm-svn: 360375
* [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptorsStefan Granitz2019-05-092-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First part of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's is still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 The address of the breakpoint site is corrupt: the 0x4 value we end up with, looks like an offset on a zero base address. When we parse the ELF section headers from the JIT descriptor, the load address for the text section we find in `header.sh_addr` is correct. The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` (follow it from `ObjectFileELF::CreateSections()`). Here we think the object type was `eTypeObjectFile` and unleash some extra logic [1] which essentially overwrites the address with a zero value. The object type is deduced from the ELF header's `e_type` in `ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF header has no representation for it [2]. Instead the in-memory ELF object states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from `lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT side instead? In fact, relocations were already applied at this point, so "Relocatable" is not quite exact.) So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call `GetType()`, which returns the explicit value or otherwise falls back to `CalculateType()`. LLDB then sets the breakpoint successfully. Next step: debug info. ``` Process 1056 stopped * thread #1, name = 'lli', stop reason = breakpoint 1.2 frame #0: 0x00007ffff7ff7000 JIT(0x3ba2030)`jitbp() JIT(0x3ba2030)`jitbp: -> 0x7ffff7ff7000 <+0>: pushq %rbp 0x7ffff7ff7001 <+1>: movq %rsp, %rbp 0x7ffff7ff7004 <+4>: movabsq $0x7ffff7ff6000, %rdi ; imm = 0x7FFFF7FF6000 0x7ffff7ff700e <+14>: movabsq $0x7ffff6697e80, %rcx ; imm = 0x7FFFF6697E80 ``` [1] It was first introduced with https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the original breaking change. The code has changed a lot since then. [2] ELF object types: https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110 Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, stella.stamenova Reviewed By: labath, clayborg Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, yurydelendik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61611 llvm-svn: 360354
* Fix up lldb after clang r360311.Richard Smith2019-05-091-2/+6
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360312
* Fix bug in ArchSpec::MergeFromGreg Clayton2019-05-081-1/+1
| | | | | | | | | | Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
* [DWARF] Centralize user_id <-> DWARFDIE conversionsPavel Labath2019-05-086-114/+55
| | | | | | | | | | | | | | | | | | | | | | | Summary: The logic for translating a user_id into a DWARFDIE was replicated in several places. This removes that redundancy and settles on a single implementation in SymbolFileDWARF. The reason for choosing that instead of DIERef was that we were always immediately converting the returned DIERef into a DWARFDIE anyway, which meant that one had to specify the SymbolFileDWARF argument twice (once to get the DIERef, and once to get the actual DIE). Also, passing a higher-level object (SymbolFileDWARF) into a lower-level one (DIERef) seemed like a less intuitive arrangement than doing things the other way around. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: tberghammer, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61648 llvm-svn: 360246
* Propagate command interpreter errors from lldlbinitJonas Devlieghere2019-05-087-3/+27
| | | | | | | | | | | | | | This patch ensures that we propagate errors coming from the lldbinit file trough the command/script interpreter. Before, if you did something like command script import syntax_error.py, and the python file contained a syntax error, lldb wouldn't tell you about it. This changes with the current patch: errors are now propagated by default. PS: Jim authored this change and I added testing. Differential revision: https://reviews.llvm.org/D61579 llvm-svn: 360216
* [Expression] Remove unused dependencyAlex Langford2019-05-072-2/+1
| | | | | | | | | lldbExpression was linking against lldbPluginExpressionParserClang, and lldbPluginExpressionParserClang was linking against lldbExpression. There's no reason lldbExpression should need anything from lldbPluginExpressionParserClang, so let's remove that dependency. llvm-svn: 360208
* [Core] Remove unused dependenciesAlex Langford2019-05-071-2/+0
| | | | llvm-svn: 360193
* [Host] Clean up dependencies of HostMacOSXObjCXXAlex Langford2019-05-071-4/+0
| | | | llvm-svn: 360178
OpenPOWER on IntegriCloud