"process launch" or "run" interpreter command.  Let's do the sleep only if
the process launch failed.  This saves about 135 seconds from the whole test
suite run time.

llvm-svn: 123806

This patch removes a potential race condition between a process monitor thread
and its parent waiting to interrogate the success/failure of the launch.

llvm-svn: 123803

llvm-svn: 123801

The previous implementation of HardwareSingleStep wrongly resumed the thread and
single-stepped over the next instruction.  Use the proper call to ProcessMonitor.

llvm-svn: 123800

Previous version simply resumed the associated thread to single step over a
single instruction which is not the intended semantics for this method.  Set the
appropriate bit in the rflags register instead.

llvm-svn: 123799

Also, this patch adds a few delimiters to the register enumeration to enable
efficient testing of register set inclusion.

llvm-svn: 123798

llvm-svn: 123797

llvm-svn: 123796

llvm-svn: 123795

This fixes a bug where the dynamic loader rendezvous was not updating its
internal state when first initialized.

llvm-svn: 123794

    rdar://problem/8875425 Found mySource->isa local variable assertion failed

llvm-svn: 123792

support for minimal type import functionality.

llvm-svn: 123787

llvm-svn: 123784

llvm-svn: 123782

Use generic CPU types instead of hard coding to mach-o when getting default byte order (patch from Stephen Wilson).

llvm-svn: 123781

llvm-svn: 123780

llvm-svn: 123779

I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.

llvm-svn: 123762

In ThreadPlanCallFunction, do the Takedown right when the thread plan gets popped.  When the function call is discarded (e.g. when it crashes and discard_on_error is true) the plan gets discarded.  You need to make sure that the stack gets restored right then, and not wait till you start again and the thread plan stack is cleared.

llvm-svn: 123716

and Enums inside classes.

llvm-svn: 123710

Apple's Objective-C 2.0 runtime.  They are enabled
if the Objective-C runtime has the proper version.

llvm-svn: 123694

llvm-svn: 123693

The test framework was relying on detecting either "run" or
"process launch" command to automatically kill the inferior.

llvm-svn: 123683

allowing timeouts & informing the user when the lock is unavailable.


Fixed problem where Debugger::Terminate was clearing the debugger list
even when the global ref count was greater than zero.

llvm-svn: 123674

    bool RegisterContextLLDB::GetPC (addr_t& pc);

to:
    bool RegisterContextLLDB::ReadPC (addr_t& pc);
    
To avoid confusion with the GetPC() function that is part of the 
lldb_private::RegisterContext:

    uint64_t RegisterContext::GetPC (uint64_t fail_value);
    
Bad things could happen if the two got intermixed and the wrong one got
called.

Fixed inifinite loop detection by watching for two frames where the
RegisterContextLLDB::CursorSP contains the same start_pc and cfa.

    

llvm-svn: 123673

Removed commented out code since it was incorrect code to begin with and we don't want anyone thinking they should put it back in.

llvm-svn: 123672

we were setting a forward-declared Objective-C class
type as being completed using an ExternalSemaSource,
but this is neither legal nor necessary.

llvm-svn: 123671

llvm-svn: 123617

long strings in "char *" (with any combo if qualifiers).

llvm-svn: 123616

V2 and we only have gdb_class_getClass, then make sure the isa isn't NULL 
before trying to call gdb_class_getClass otherwise we end up deadlocking the
objective C runtime.

llvm-svn: 123615

llvm-svn: 123614

the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a 
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.

A few months ago I worked with the llvm/clang folks to have the 
ExternalASTSource class be able to complete classes if there weren't completed
yet:

class ExternalASTSource {
....

    virtual void
    CompleteType (clang::TagDecl *Tag);
    
    virtual void 
    CompleteType (clang::ObjCInterfaceDecl *Class);
};

This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.

This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
  objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
  types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
  ClangASTType, and more) can now be iterating through children of any type,
  and if a class/union/struct type (clang::RecordType or ObjC interface) 
  is found that is incomplete, we can ask the AST to get the definition. 
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
  all child SymbolFileDWARF classes will share (much like what happens when
  we have a complete linked DWARF for an executable).
  
We will need to modify some of the ClangUserExpression code to take more 
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.

llvm-svn: 123613

This patch is enough to have shared objects recognized by LLDB.  We can handle
position independent executables.  We can handle dynamically loaded modules
brought in via dlopen.

The DYLDRendezvous class provides an interface to a structure present in the
address space of ELF-based processes.  This structure provides the address of a
function which is called by the linker each time a shared object is loaded and
unloaded (thus a breakpoint at that address will let LLDB intercept such
events), a list of entries describing the currently loaded shared objects, plus
a few other things.

On Linux, processes are brought up with an auxiliary vector on the stack.  One
element in this vector contains the (possibly dynamic) entry address of the
process.  One does not need to walk the stack to find this information as it is
also available under /proc/<pid>/auxv.  The new AuxVector class provides a
convenient read-only view of this auxiliary vector information.  We use the
dynamic entry address and the address as specified in the object file to compute
the actual load address of the inferior image.  This strategy works for both
normal executables and PIE's.

llvm-svn: 123592

llvm-svn: 123583

llvm-svn: 123513

llvm-svn: 123509

stuff soon when we get a fix for looking up the "OBJC_IVAR_$_Class.ivar"
style symbols into IRForTarget::ResolveExternals() next week.

llvm-svn: 123507

This patch simply allows the tree to build.  A proper implementation still needs
to be provided.

llvm-svn: 123504

llvm-svn: 123503

    
Propagate the environment if one is not provided.  Also, do not allocate the
monitor threads launch arguments on the stack.

llvm-svn: 123502