step through the complete function looking for any epilogue
instructions.  If we find an epilogue sequence, re-instate
the correct unwind instructions if there is more code past
that epilogue -- this will correctly handle an x86 function
with multiple epilogues in it.

NB there is still a bug with the "eh_frame augmented" 
UnwindPlans and mid-function epilogues.  Looking at that next.

<rdar://problem/18863406> 

llvm-svn: 225770

llvm-svn: 224932

This completes the compact unwind support for x86 targets.  

I'm still skipping the UNWIND_X86_64_MODE_STACK_IND encodings for
x86_64 right now because clang was emitting bad data for this form
until it was fixed in r217020 circa Sep 2014.

arm64 parsing still needs to be added.

llvm-svn: 224698

Most of the changes are to the FuncUnwinders class -- as we've added
more types of unwind information, the way this class was written was
making it a mess to maintain.  Instead of trying to keep one
"non-call site" unwind plan and one "call site" unwind plan, track
all the different types of unwind plans we can possibly retrieve for
each function and have the call-site/non-call-site accessor methods
retrieve those.

Add a real "fast unwind plan" for x86_64 / i386 -- when doing an
unwind through a function, this only has to read the first 4 bytes 
to tell if the function has a standard prologue sequence.  If so, 
we can use the architecture default unwind plan to backtrace 
through this function.  If we try to retrieve the save location for
other registers later on, a real unwind plan will be used.  This
one is just for doing fast backtraces.

Change the compact unwind plan importer to fill in the valid address
range it is valid for. 

Compact unwind, in theory, may have multiple entries for a single
function.  The FuncUnwinders rewrite includes the start of supporting
this correctly.  In practice compact unwind encodings are used for
the entire range of the function today -- in fact, sometimes the same
encoding is used for multiple functions that have the same unwind
rules.  But I want to handle a single function that has multiple
different compact unwind UnwindPlans eventually.

llvm-svn: 224689

When lldb has a binary with protected section contents,
don't use the on-disk representation of that compact 
uwnind -- read it only out of live memory where it has
been decrypted.

llvm-svn: 224670

The compact unwind importer is getting the wrong unwind info for one
case that I found.  I haven't been able to fix the problem tonight 
and I don't want to leave TOT behaving incorrectly, so just ignore
compact unwind until I can get to the bottom of this.

llvm-svn: 224321

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

llvm-svn: 223687

section for x86_64 and i386 targets on Darwin systems.  Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it.  The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.

This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them.  There may need to be some bug fixing over the next couple weeks as
I exercise and test it further.  But I think it's fine right now so I'm
committing it.

<rdar://problem/13220837> 

llvm-svn: 223625

resulted in hard-to-track-down crashes.  Sigh.

llvm-svn: 223575

encounter clang::ExternalASTSources that are not instances
of ClangExternalASTSourceCommon.  We used to blithely
assume that all are, and so we could use static_cast<>.
That's no longer the case, so we have to have these AST
sources register themselves.

llvm-svn: 223560

support to LLDB.  It includes the following:

- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
  rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
  DeclVendors instead.
- Provided a few convenience functions on
  ClangASTContext to make that easier.

llvm-svn: 223433

retrieves the personality routine addr and the
LSDA addr.  Don't bother checking with the
"non-call site" unwind plan - this kind of
information is only going to come from the 
call site unwind plan.

llvm-svn: 222226

eh_frame data.  These two pieces of information are used in the
process of exception handler unwinding on SysV ABI systems.

This patch reads the data from the eh_frame section 
(DWARFCallFrameInfo.cpp), allows for it to be saved & read out
of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well
as printing the information in the UnwindPlan::Dump method - and
adds methods to the FuncUnwinders object so that higher levels
can query if a given function has an LSDA / personality routine
defined.

It's only lightly tested, but seems to be working correctly as long
as your have this information in eh_frame.  Does not address getting
this information from compact unwind yet on Darwin systems.

<rdar://problem/18742797> 

llvm-svn: 222214

Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener. 
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:

    size_t
    Target::UnloadModuleSections (const ModuleList &module_list);

    size_t
    Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);

llvm-svn: 222167

relative paths, like:

/whatever/llvm/lib/Sema/../../include/llvm/Sema/

That causes problems with our type uniquing, since we use the declaration file
and line as one component of the uniquing, and different ways of getting to the
same file will have different directory spellings, though they are functionally
equivalent.  We end up with two copies of the exact same type because of this, 
and that makes the expression parser give "duplicate type" errors.

I added a method to resolve paths with ../ in them and used that in the FileSpec::Equals,
for comparing Declarations and for doing Breakpoint compares as well, since they also
suffer from this if you specify breakpoints by full path (since nobody knows what
../'s to insert...)

<rdar://problem/18765814>

llvm-svn: 222075

Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA).  LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.

Discussed with Jason Molenda, who also provided the initial patch for this.

Reviewers: jasonmolenda

Reviewed By: jasonmolenda

Subscribers: emaste, lldb-commits

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

llvm-svn: 221788

let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.

This fix is for <rdar://problem/18683658>.  

I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios 
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719> 
that I've fixed over the last 6-9 months.

llvm-svn: 221238

llvm-svn: 221018

llvm-svn: 220891

Fix the NSPathStore2 data formatter to actually handle the explicit length stored inside the object. The meat of this commit, however, is a nice little API for easily adding new __lldb_autogen_ helper types to an AST context

llvm-svn: 220881

When trying to get the element type of an array type, do not go to the canonical type, since that will strip typedefs where we want them to be preserved. Fixes rdar://15453076

llvm-svn: 220810

clang static analyzer fixit.

llvm-svn: 220024

llvm-svn: 219912

clang static analyzer fixit.

llvm-svn: 219905

possibly use it uninitialized in a log message later.
clang static analyzer fixit.

llvm-svn: 219865

exists a code path where it could be used while uninitialized.
clang static analyzer fixit.

llvm-svn: 219769

output style can be customized.  Change the built-in default to be
more similar to gdb's disassembly formatting.

The disassembly-format for a gdb-like output is

${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: 

The disassembly-format for the lldb style output is

{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: 

The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.

<rdar://problem/9885398> 

llvm-svn: 219544

works, as do breakpoints, run and pause, display zeroth frame.

See
http://reviews.llvm.org/D5503

for a fuller description of the changes in this commit.

llvm-svn: 218596

For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case

llvm-svn: 218132

Change the ClangASTMap implementation to use a thread-safe wrapper over llvm::DenseMap. This helps avoid a certain class of spins per <rdar://problem/18160764>

llvm-svn: 217888

llvm-svn: 217862

Change SBType.GetMemberFunctionAtIndex() to return an object describing the member function in more detail. A type was really quite vague. This now has function name, kind, as well as function type

llvm-svn: 217828

Add logic to LLDB to figure out the types of member functions of C++ classes. Add plumbing for that all the way up to the SB layer

llvm-svn: 217701

Copy unwind plan instead of modifying it directly, so "image show-unwind" prints different plans for asynchronous and synchronous.

Change by Tong Shen.

llvm-svn: 216416

name/from-compiler settings to indicate that it was augmented
by assembly profiling.

llvm-svn: 216412

In practice, 64bit eh_frame is not used even for x86_64 binaries. The main reason is in eh_frame we almost always use pc-relative addressing, so addresses are within 32bits and gcc just sticks to 32bit eh_frame.

I generated 64bit eh_frame for Android Java runtime and unwind successfully in gdb, and in lldb with this patch.

Patch by Tong Shen.

llvm-svn: 216409

We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.

Change by Tong Shen.

llvm-svn: 216406

with binaries in the dyld shared cache (esp on iOS) where the file
address for the executable binary (maybe from memory, maybe from
an expanded copy of the dyld shared cache) is different from the
file address in the dSYM.  In that case, ObjectFileMachO replaces
the file addresses from the original binary with the dSYM file
addresses (usually 0-based) -- lldb doesn't have a notion of two
file addresses for a given module so they need to agree.

There was a cache of file addresses over in the Symtab so I added
a method to the Module and the objects within to clear any file address
caches if they exist, and added an implementation in the Symtab
module to do that.
<rdar://problem/16929569> 

llvm-svn: 216258

What it does:

- it introduces a concept of EncodingToType to the ObjCLanguageRuntime
  The ObjC runtime has a "type encoding" feature that describes types as strings
  The EncodingToType is a decoder for that format, making types out of type encoding strings
This feature already existed in some shape as we were using it to create method signatures out of the runtime, but this checkin extends the parser to support the full syntax, and moves things so that more parts of LLDB have access to this decoder

- it splits the ClassDescriptorV2 object to its own file, it was starting to grow too large

- it adds to the ClassDescriptor mechanism a notion of ivar storage; the ObjC runtime vends ivar information as well as method information
While ivar information is not ready for prime type (i.e. we don't want to add it to the runtime generated types for expression evaluator usage), there are potentially useful scenarios in which realizing ivar types could be useful. For now, the ClassDescriptor is going to hold ivar information directly. Existing code already allows describing ivars, this patch hooks those moving parts up so that one can actually ask a ClassDescriptor about ivars for the class it represents

and as a couple minor niceties:
- it makes it possible to retrieve the LLDB ClangASTContext that is associated to a clang::ASTContext
- it extends the ValueObject-to-ClassDescriptor API in the language runtime to deal correctly with base-class hierarchies

llvm-svn: 216026

llvm-svn: 215783