Commit Graph

8321 Commits

Author SHA1 Message Date
Aidan Dodds b0be30f71a [Renderscript] Refactor .rs.info parser.
This patch refactors the .rs.info table parser so that its more in line with the current language runtime code.

llvm-svn: 261202
2016-02-18 10:59:46 +00:00
Eugene Zelenko 9394d772c0 Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes.
llvm-svn: 261179
2016-02-18 00:10:17 +00:00
Enrico Granata 984af07ae5 Apple simulator platforms don't have a shared cache to load Objective-C class information from
This code was doing the right thing for the iOS simulator, but not other simulator platforms

Fix it by making the warning not happen for all platforms whose name ends in "-simulator"
Since this code lives in AppleObjCRuntimeV2.cpp, this already only applies to Apple platforms by definition, so I am not too worried about conflicts with other vendors

llvm-svn: 261165
2016-02-17 22:14:41 +00:00
Tamas Berghammer be379e1590 Revert "Use BKPT instead of UDF for arm/thumb breakpoints"
This reverts commit 293c18e067d663e0fe93e6f3d800c2a4bfada2b0.

The BKPT instruction generates SIGBUS instead of SIGTRAP in the Linux
kernel on Nexus 6 - 5.1.1 (kernel version 3.10.40). Revert the CL
until we can figure out how can we hanble the SIGBUS or how to get
back a SIGTRAP using the BKPT instruction.

llvm-svn: 260969
2016-02-16 15:14:36 +00:00
Jason Molenda ebeff4c11e Fix buildbot failure because I got an include path wrong.
llvm-svn: 260932
2016-02-16 04:20:56 +00:00
Jason Molenda 62e0681afb Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through.  This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through.  I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week.  I added a new
lldb-private-defines.h to hold the definition for now.

Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.

I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.

This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.

llvm-svn: 260930
2016-02-16 04:14:33 +00:00
Saleem Abdulrasool 1ee07253c7 Silence some clang warnings
Silences -Wmissing-brace and -Wformat-pedantic warnings from clang on Linux.  NFC.

llvm-svn: 260914
2016-02-15 21:50:28 +00:00
Jim Ingham b6bdfc522c Refinement of r260624. It is possible somebody might try to add to the map
while we are finalizing its elements.  Prevent that.

<rdar://problem/24554920>

llvm-svn: 260909
2016-02-15 20:04:15 +00:00
Saleem Abdulrasool 2f1d3ac99d ExpressionParser: silence some GCC warnings
Silence a -Wreorder warning about order of member initialization and a
-Wqual-cast warning about casting away constness.  NFC.

llvm-svn: 260868
2016-02-15 03:23:14 +00:00
Jason Molenda 5f826bbc51 Additional fix to my change in r259983 to handle the
case where a core file has a kernel binary and a user
process dyld in the same one.  Without this, we were
always picking the dyld and trying to process it as a
kernel.

<rdar://problem/24446112> 

llvm-svn: 260803
2016-02-13 04:15:02 +00:00
Jim Ingham cbf6f9b243 Adding an SBThread::StepInto that takes an end-line, also moved the code that figures
out the address range for the step to SymbolContext.

llvm-svn: 260772
2016-02-13 00:31:47 +00:00
Sean Callanan 2a8fa2a888 Removed many JIT workarounds from IRForTarget.
Since IRExecutionUnit is now capable of looking up symbols, and the JIT is up to
the task of generating the appropriate relocations, we don't need to do all the
work that IRForTarget used to do to fixup symbols at the IR level.

We also don't need to allocate data manually (with its attendant bugs) because
the JIT is capable of doing so without crashing.

We also don't need the awkward lldb.call.realName metadata to determine what
calls are objc_msgSend, because they now just reference objc_msgSend.

To make this work, we ensure that we recognize which symbols are extern "C" and
report them to the compiler as such.  We also report the full Decl of functions
rather than just making up top-level functions with the appropriate types.

This should not break any testcases, but let me know if you run into any issues.

<rdar://problem/22864926>

llvm-svn: 260768
2016-02-13 00:01:46 +00:00
Sean Callanan f45270342c Fix stripping of _ when looking for symbols in IRExecutionUnit.
Previously we would try both versions of a symbol -- the one with _ in it and
the one without -- in all cases, because we didn't know what the current
platform's policy was.  However, stripping _ is only necessary on platforms
where _ is the prefix for global symbols.

There's an API that does this, though, on llvm::DataLayout, so this patch fixes
IRExecutionUnit to use that API to determine whether or not to strip _ from the
symbol or not.

llvm-svn: 260767
2016-02-12 23:55:13 +00:00
Enrico Granata fdecea7f59 Remove an unnecessary include
llvm-svn: 260761
2016-02-12 23:12:27 +00:00
Enrico Granata 75995b5e86 Data formatter support for libc++ std::atomic<T>
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"

All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable

Fixes rdar://24329405

llvm-svn: 260752
2016-02-12 22:18:24 +00:00
Sean Callanan 8c05fb9fff Disable recognition of "using" declarations at translation-unit level.
Currently CountDeclLevels uses the ASTs which have no distinction between
separate translation units.  If one .o file has a "using" declaration at
translation unit level, that "using" declaration will be in the same translation
unit as functions from other .o files in the same module.  This leads to
erroneous name conflicts as the CountDeclLevels-based function filtering logic
accepts too many fucntions.

In the future we will identify the translation units for top-level Decls more
reliably and restore that functionality.  There's a TODO to that effect in the
code.

llvm-svn: 260747
2016-02-12 21:55:05 +00:00
Sean Callanan 8c62daf250 IRInterpreter now recognizes expressions with constants it doesn't handle.
If an instruction has a constant that IRInterpreter doesn't know how to deal
with (say, an array constant, because we can't materialize it to APInt) then we
used to ignore that and only fail during expression execution.  This is annoying
because if IRInterpreter had just returned false from CanInterpret(), the JIT
would have been used.

Now the IRInterpreter checks constants as part of CanInterpret(), so this should
hopefully no longer be an issue.

llvm-svn: 260735
2016-02-12 21:16:58 +00:00
Sean Callanan b281480203 Centralized symbol lookup in IRExecutionUnit, and fixed the code model.
I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a
dreadful hack working around no-longer-existing JIT bugs.  Thanks to our 
contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have,
so I've cleaned them up a bit and moved them over to IRExecutionUnit.

Also for historical reasons, IRExecutionUnit used the "Small" code model on non-
ELF platforms (namely, OS X).  That's no longer necessary, and we can use the
same code model as everyone else on OS X.  I've fixed that.

llvm-svn: 260734
2016-02-12 21:11:25 +00:00
Siva Chandra 29d9bea93f Adjust for Python-3.
Summary:
This does not yet give us a clean testsuite run but it does help with:
1. Actually building on linux
2. Run the testsuite with over 70% tests passing on linux.

Reviewers: tfiala, labath, zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D17182

llvm-svn: 260721
2016-02-12 20:30:47 +00:00
Sean Callanan 7b3ef05a37 Objective-C++ is a kind of C++.
llvm-svn: 260715
2016-02-12 19:47:57 +00:00
Sean Callanan 92734d1b2b Make Target::CalculateProcess() return a sensible result.
The Calculate* functions in general should not derive any information that isn't
implicit, but for Target the process pointer is a member so it's fine to return
it for CalculateProcess().

llvm-svn: 260713
2016-02-12 19:45:31 +00:00
Enrico Granata 2543d29048 The data formatters for NSArray, NSDictionary and (only partially) NSSet contain logic to inspect the objects without running code.
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.

The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.

Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.

This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.

While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.

llvm-svn: 260664
2016-02-12 07:50:15 +00:00
Greg Clayton 9ddad935b9 Don't crash if we have a DIE that has a DW_AT_ranges attribute and yet the SymbolFileDWARF doesn't have a DebugRanges. If this happens print a nice error message to prompt the user to file a bug and attach the offending DWARF file so we can get the correct compiler fixed.
<rdar://problem/24458016>

llvm-svn: 260626
2016-02-12 00:07:16 +00:00
Jim Ingham 0ea010aecb When calling TypeSystemMap::Clear, objects being destroyed in the process of
clearing the map ended up calling back into the TypeSystemMap to do lookups.  
Not a good idea, and in this case it would cause a deadlock.

You would only see this when replacing the target contents after an exec, and only if you 
had stopped before the exec, evaluated an expression, then continued
on to the point where you did the exec.  

Fixed this by making sure the TypeSystemMap::Clear tears down the TypeSystems in the map before clearing the map.
I also add an expression before exec to the TestExec.py so that we'll catch this
issue if it crops up again in the future.

<rdar://problem/24554920>

llvm-svn: 260624
2016-02-12 00:03:19 +00:00
Greg Clayton 565aaf6194 Removed a bad assertion:
assert(((SymbolFileDWARF*)m_ast.GetSymbolFile())->UserIDMatches(die.GetDIERef().GetUID()) &&
       "Adding incorrect type to forward declaration map");

The problem is that "m_ast.GetSymbolFile()" can return a SymbolFileDWARFDebugMap. The code is doing the right thing if the assertion is ignored.

<rdar://problem/24437972>

llvm-svn: 260618
2016-02-11 23:36:57 +00:00
Adrian McCarthy 6fadea62b5 Improve ReadRegister for RegisterContextWindowsx86
In some circumstances (notably, certain minidumps), the thread CONTEXT does not have values for the
control registers (EIP, ESP, EBP, EFLAGS).  There are flags in the CONTEXT which indicate which
portions are valid, but those flags weren't checked.  The old code would not detect this and give a
garbage value for the register.  The new code will log the problem and return an error.

I consolidated the error checking and logging into a helper function, which makes the big switch
statement easier to read and verify.

Ran tests to ensure this doesn't break anything.  Manually verified that a minidump without info on
the control registers now indicates the problem instead of giving bad information.

Differential Review: http://reviews.llvm.org/D17152

llvm-svn: 260559
2016-02-11 18:24:57 +00:00
Aidan Dodds 72f775253f [Renderscript] Fix typo in mips64 argument reading code.
A typo in the mips64 argument reading code would cause register passed arguments to be truncated to 32bits.

llvm-svn: 260546
2016-02-11 17:17:12 +00:00
Aidan Dodds f478678549 [Renderscript] Refactor target argument reading code.
This patch reworks the function argument reading code, allowing us to annotate arguments with their types.  The type/size information is needed to correctly parse arguments passed on the stack.

llvm-svn: 260525
2016-02-11 15:16:37 +00:00
Omair Javaid 62498ff8f5 Handle floating-point type homogeneous aggregate return values in ABISysV_arm
For details refer to review link given below.

Differential revision: http://reviews.llvm.org/D16975

llvm-svn: 260512
2016-02-11 11:41:22 +00:00
Jim Ingham b4a5aa239c Revert 260436. I pretty consistently upper-case the letter I use for the
short option as an aid to memory.  Like it's w because of the W in throW.

That helps me remember.  If we are going to take these out we should take them
all out.  But I kind of like them.

llvm-svn: 260452
2016-02-10 22:30:20 +00:00
Sean Callanan 3f9de74ba1 When importing Objective-C protocols, mark them as having external decls.
We already do this for Objective-C interfaces, but we never handled protocols
because the DWARF didn't represent them.  Nowadays, though, we can import them
from modules, and we have to mark them properly.

<rdar://problem/24193009>

llvm-svn: 260445
2016-02-10 22:00:32 +00:00
Enrico Granata 909e2cdc54 No reason for these two letters to be uppercase
llvm-svn: 260436
2016-02-10 21:30:20 +00:00
Greg Clayton ae088e52f3 Now that SymbolFileDWARF supports having types in completely separate .pcm file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument:
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
    
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. 

This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. 

<rdar://problem/24581488>

llvm-svn: 260434
2016-02-10 21:28:13 +00:00
Tamas Berghammer 5bfd4d0008 Revert "Improve the handling of missing elf symtab and missing symbol sizes"
This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce.

The commit caused several test failure on the OSX build bot.

llvm-svn: 260377
2016-02-10 12:10:58 +00:00
Ewan Crawford ea0636b554 [RenderScript] Refactor allocation expressions
Patch refractors RS plugin code specifying how format strings are used to JIT the runtime.

Author: Dean De Leo <dean@codeplay.com>
llvm-svn: 260372
2016-02-10 11:23:27 +00:00
Tamas Berghammer ed844cbc0f Improve the handling of missing elf symtab and missing symbol sizes
* Generate artificial symbol names from eh_fame during symbol parsing
  so these symbols are already present when we calcualte the size of
  the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
  it have to last until the end of the parent section.

Differential revision: http://reviews.llvm.org/D16996

llvm-svn: 260369
2016-02-10 10:43:34 +00:00
Tamas Berghammer 10e9923841 Fix handling of the arm IT instruction in the unwinder
The IT instruction can specify condition code for up to 4 consecutive
instruction and it is used quite often by clang in epilogues causing
an issue when trying to unwind from locations covered by the IT
instruction and for locatins inmediately after the IT instruction.

Changes made to fix it:
* Introduce the concept of conditional instruction block what is a list
  of consecutive instructions with the same condition. We update the
  unwind information during the conditional instruction block and when
  we reach the end of it (first instruction with a differemt condition)
  then we restore the unwind information we had before the condition.
* Fix a bug in the ARM instruction emulator where neither PC nor the
  ITSTATE was advanced when we reached an instruction what we can't
  decode.

After the change we have no regression on android-arm running the
regular test suit and TestStandardUnwind also passes when running it
with clang as the compiler (previously it failed on an IT instruction).

Differential revision: http://reviews.llvm.org/D16814

llvm-svn: 260368
2016-02-10 10:42:13 +00:00
Tamas Berghammer 1b6dacbb86 Use BKPT instead of UDF for arm/thumb breakpoints
The UDF instruction is deprecated in armv7 and in case of thumb2
instructions set it don't work well together with the IT instruction.

Differential revision: http://reviews.llvm.org/D16853

llvm-svn: 260367
2016-02-10 10:42:00 +00:00
Jim Ingham c17d6bdbfb This is an idea to make "thread step-in --target" work for the common
case where you have:

1 ->    foo (bar(),
2            baz(),
3            lala());
4

You are sitting on line 1, and want to step into foo, but not bar, baz & lala.  Unfortunately
there are line table entries for lines 1-3, and lldb doesn't know anything about the nesting
of statement in these lines.  So we'll have to use the user's intelligence...  This patch adds:

(lldb) thread step-in -t foo --end-line 4

That tells lldb to keep stepping in till line 4, but stop if you step into foo.  I think I would
remember to use this when faced with some of the long gnarly call sequences in lldb.  But there
might be ways I haven't thought of to make it more convenient.  Jason suggests having "end" as a
special token for --end-line which just means keep going to the end of the function, I really want
to get into this thing...

There should be an SB API and tests, which will come if this seems useful.

llvm-svn: 260352
2016-02-10 03:25:24 +00:00
Adrian McCarthy e286b8d652 Don't dereference the first element of an empty container.
llvm-svn: 260331
2016-02-10 00:06:50 +00:00
Greg Clayton 343f898443 Added code that was commented out during testing to stops template member functions from being added to class definitions (see revision 260308 for details).
<rdar://problem/24483905>
<rdar://problem/24508374>

llvm-svn: 260322
2016-02-09 23:25:54 +00:00
Greg Clayton fb85e6288b Fixed many issues that were causing differing type definition issues to show up when parsing expressions.
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:

    class A
    { 
        <template T>
        void Foo(T t);
    };
    
    The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
    class A
    {
        void Foo(int t);
        void Foo(double t);
    };
    
    And a version from b.cpp that used a "float" overload to look like:
    class A
    {
        void Foo(float t);
    };

    And a version from c.cpp that use no overloads to look like:    
    
    class A
    {
    };
    
    Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
    a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
    b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug: 
    <rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
    This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext. 
    
    So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
    
    class A
    {
    };
    
    And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
    
    <rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
    
    before we can do anything about it in LLDB.

This bug mainly fixed the following Apple radar:

<rdar://problem/24483905>

llvm-svn: 260308
2016-02-09 22:36:24 +00:00
Greg Clayton 36ab260b0d Don't complete a class type just to test if it is a class. Code in CompilerType and in clang::QualType knows how to complete a type if it needs to.
llvm-svn: 260299
2016-02-09 22:09:26 +00:00
Jim Ingham cc3a4595f7 Mention the --all-files option in the -p help string.
llvm-svn: 260247
2016-02-09 18:53:49 +00:00
Pavel Labath b625a0e1bc Fix invalid shift operator overload in Scalar
Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().

Reviewers: sagar, tberghammer, labath

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D16868

Patch by Marianne Mailhot-Sarrasin

llvm-svn: 260239
2016-02-09 17:28:01 +00:00
Enrico Granata b1cf558d83 Fix an issue where pressing CTRL+C in the interactive script interpreter causes LLDB to crash
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state

The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.

None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself

llvm-svn: 260199
2016-02-09 05:46:47 +00:00
Bhushan D. Attarde b4fd8bb27e [LLDB][MIPS] Fix TestExpressionInSyscall.py for MIPS
SUMMARY:
    This patch fixes TestExpressionInSyscall.py and solves bug 23659 for MIPS.
    Corrected indentation at couple of places.
    
    Reviewers: clayborg
    Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
    Differential Revision: http://reviews.llvm.org/D16916

llvm-svn: 260072
2016-02-08 04:35:51 +00:00
Jason Molenda 880988af09 ProcessMachCore scans through the core file pages looking for a
user process dyld binary and/or a mach kernel binary image.  By
default, it prefers the kernel if it finds both.

But if it finds two kernel binary images (which can happen when
random things are mapped into memory), it may pick the wrong
kernel image.  

DynamicLoaderDarwinKernel has heuristics to find a kernel in memory;
once we've established that there is a kernel binary in memory,
call over to that class to see if it can find a kernel address via
its search methods.  If it does, use that.

Some minor cleanups to DynamicLoaderDarwinKernel while I was at it.

<rdar://problem/24446112> 

llvm-svn: 259983
2016-02-06 04:55:26 +00:00
Enrico Granata 41571781c0 Per Jim's suggestion, move checks that we're not mixing and matching Debuggers and Commands deeper in the bowels of LLDB
NFC

llvm-svn: 259972
2016-02-06 01:36:07 +00:00
Enrico Granata 0a66e2f135 Fix an issue where certain CommandObjects (or Options thereof) were being created once, bound to a specific CommandInterpreter (and hence a specific Debugger), and then cached for reuse across different Debugger instances
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes

Fixes rdar://24460882

llvm-svn: 259964
2016-02-06 00:43:07 +00:00