llvm-svn: 124250

it to interpret a "this" variable that was merely
a pointer -- that is, not a class pointer -- as
meaning that the current context was inside a C++
method.  This bug would prevent expressions from
evaluating correctly in regular C code if there
was a pointer variable named "this" in scope.

llvm-svn: 124117

llvm-svn: 124051

llvm-svn: 124014

Added a safeguard to ensure that the user does not create variables that override persistent result variables.

llvm-svn: 124001

llvm-svn: 123855

500 ms.

Make MachThreadList more threadsafe.

Added code to make sure the thread register state was properly flushed for x86_64.

Fixed an missing return code for the current thread in the new thread suffix code.

Improved debugserver logging.

llvm-svn: 123815

support for minimal type import functionality.

llvm-svn: 123787

llvm-svn: 123784

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

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

llvm-svn: 123694

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

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

variables.

llvm-svn: 123398

by LLDB.  Instead of being materialized into the input structure
passed to the expression, variables are left in place and pointers
to them are materialzied into the structure.  Variables not resident
in memory (notably, registers) get temporary memory regions allocated
for them.

Persistent variables are the most complex part of this, because they
are made in various ways and there are different expectations about
their lifetime.  Persistent variables now have flags indicating their
status and what the expectations for longevity are.  They can be
marked as residing in target memory permanently -- this is the
default for result variables from expressions entered on the command
line and for explicitly declared persistent variables (but more on
that below).  Other result variables have their memory freed.

Some major improvements resulting from this include being able to
properly take the address of variables, better and cleaner support
for functions that return references, and cleaner C++ support in
general.  One problem that remains is the problem of explicitly
declared persistent variables; I have not yet implemented the code
that makes references to them into indirect references, so currently
materialization and dematerialization of these variables is broken.

llvm-svn: 123371

a method:

    void RegisterContext::InvalidateIfNeeded (bool force);

Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache 
when it doesn't need to be.

Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
  these before and it was causing us to read at least three registers every
  time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
  info. Prior to this fix we would continually send a qThreadStopInfo packet
  over and over when any thread stop info was requested. We now note the stop
  ID that the stop info was requested for and avoid multiple requests.

Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.

Fixed an bug in the ValueObject code that would cause children to not be 
displayed.

llvm-svn: 123127

an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.

Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the 
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each 
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete 
frame itself.

So now the stack frames and the register contexts should behave much better.

llvm-svn: 122976

were not being created in the proper way, meaning
results were getting lost.

llvm-svn: 122800

Provide full qualification for #include's.

llvm-svn: 122274

line commands can use the current thread/frame.

Fixed an issue with expressions that get sandboxed in an objective C method
where unichar wasn't being passed down.

Added a "static size_t Scalar::GetMaxByteSize();" function in case we need
to know the max supported by size of something within a Scalar object.

llvm-svn: 122027

(from Sean's commit a minute ago)

llvm-svn: 121954

can avoid running the code in the target if the
expression's result is known and the expression
has no side effects.

Right now this feature is quite conservative in
its guess about side effects, and it only computes
integer results, but the machinery to make it more
sophisticated is there.

llvm-svn: 121952

values or persistent expression variables. Now if an expression consists of
a value that is a child of a variable, or of a persistent variable only, we
will create a value object for it and make a ValueObjectConstResult from it to
freeze the value (for program variables only, not persistent variables) and
avoid running JITed code. For everything else we still parse up and JIT code
and run it in the inferior. 

There was also a lot of clean up in the expression code. I made the 
ClangExpressionVariables be stored in collections of shared pointers instead
of in collections of objects. This will help stop a lot of copy constructors on
these large objects and also cleans up the code considerably. The persistent
clang expression variables were moved over to the Target to ensure they persist
across process executions.

Added the ability for lldb_private::Target objects to evaluate expressions.
We want to evaluate expressions at the target level in case we aren't running
yet, or we have just completed running. We still want to be able to access the
persistent expression variables between runs, and also evaluate constant 
expressions. 

Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects
can now dump their contents with the UUID, arch and full paths being logged with
appropriate prefix values.

Thread hardened the Communication class a bit by making the connection auto_ptr
member into a shared pointer member and then making a local copy of the shared
pointer in each method that uses it to make sure another thread can't nuke the
connection object while it is being used by another thread.

Added a new file to the lldb/test/load_unload test that causes the test a.out file
to link to the libd.dylib file all the time. This will allow us to test using
the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else.

llvm-svn: 121745

the code to pass the _cmd pointer has been improved, and _cmd
is now set to the value of _cmd for the current context, as
opposed to being simply NULL.

llvm-svn: 121739

access to the members of the Objective-C self object.

The approach we take is to generate the method as a
@category on top of the self object, and to pass the
"self" pointer to it.  (_cmd is currently NULL.)

Most changes are in ClangExpressionDeclMap, but the
change that adds support to the ABIs to pass _cmd
touches a fair amount of code.

llvm-svn: 121722

between clients of the LLDB API and the expression
parser.

llvm-svn: 121193

LLDB expression execution.
We also now print the argument structure after execution,
to allow us to verify that the expression did indeed
execute correctly.

llvm-svn: 121126

llvm-svn: 121099

when calling built-ins.

llvm-svn: 121070

wrongly as the target of a pointer rather than the
SEL pointer itself.  This caused incorrect behavior
when dealing with Objective-C selector variables.

llvm-svn: 121048

(for example, string literals) were being flagged
erroneously as undefined external variables.

llvm-svn: 120972

llvm-svn: 120834

llvm-svn: 120788

so that it is not referring to potentially stale
state during IR execution.

This was done by introducing modular state (like
ClangExpressionVariable) where groups of state
variables have well-defined lifetimes:

- m_parser_vars are specific to parsing, and only
  exist between calls to WillParse() and DidParse().

- m_struct_vars survive for the entire execution
  of the ClangExpressionDeclMap because they
  provide the template for a materialized set of
  expression variables.

- m_material_vars are specific to a single
  instance of materialization, and only exist
  between calls to Materialize() and
  Dematerialize().

I also removed unnecessary references to long-
lived state that really didn't need to be referred
to at all, and also introduced several assert()s
that helped me diagnose a few bugs (fixed too).

llvm-svn: 120778

TagDecl subclasses and Objective C interfaces to complete themselves through
the ExternalASTSource class.

llvm-svn: 120749

pointers are used.  Previously, they caused a crash
in the JIT because we didn't resolve them correctly.

llvm-svn: 120728

in C++ methods.  There were two fixes involved:

 - For an object whose contents are not known, the
   expression should be treated as a non-member, and
   "this" should have no meaning.

 - For a const object, the method should be declared
   const as well.

llvm-svn: 120606

persistent variables even after the parser has
finished running.

llvm-svn: 120521

llvm-svn: 120520

copied by the copy constructor for ClangExpressionVariable.
This meant that a NULL m_register_info wouldn't be
copied, and instead the field was uninitialized, potentially
confusing the materializer.

llvm-svn: 120472