llvm-svn: 228933

Make a more complete fix for always supplying an execution context when getting byte sizes from types.

There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.

Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.

llvm-svn: 228892

- you have a type that contains a typedef to a VectorType or an ExtVectorType
- that type is returned from an ARM function that LLDB steps over so we try to figure out the return type
- we try to determine if the type is a homogeneous aggregate type and we crash

We get not using getAs() when we should have been and using llvm::cast caused an assertion crash when the typedef type didn't return a valid VectorType or ExtVectorType.

<rdar://problem/19646550>

llvm-svn: 228771

The problem occurred when we had incorrect address ranges in the debug map that included the padding between functions causing the end address of a line table entry to fall into an inlinked (next function) address range.

<rdar://problem/19721144>

llvm-svn: 228707

Fixed bugs in the multi-threaded access in HostInfoBase. Prior to this fix, static bool variables were used but this is not sufficient. We now use std::call_once in all places where the previous static bool code was used to try to implement thread safety.

This was causing code that opened multiple targets to try and get a path to debugserver from the GDB remote communication class, and it would get the LLDB path and some instances would return empty strings and it would cause debugserver to not be found.

<rdar://problem/18756927>

llvm-svn: 227935

llvm-svn: 227383

llvm-svn: 227342

Emit a warning the first time that one tries to resolve the size of a type passing a nullptr ExecutionContext - but only when it might actually make a difference

This should help us find these cases and act on them

llvm-svn: 227289

And since enough of these are doing the right thing, add a test case to verify we are doing the right thing with freeze drying ObjC object types

Fixes rdar://18092770

llvm-svn: 227282

Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime

This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)

This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet

llvm-svn: 227274

Apply the transformation to the static type as well as the dynamic type. It doesn't make sense to carry along an untransformed static type

llvm-svn: 227166

llvm-svn: 226892

i386/x86_64 functions.  The stack size was being multiplied by the
pointer size incorrectly.  The register permutation placeholders
(UNWIND_X86_REG_NONE) were decrementing the stack offset of the
saved registers when it should not have been.

<rdar://problem/19570035> 

llvm-svn: 226889

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb

llvm-svn: 226199

This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.

This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.

The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.

<rdar://problem/18945678> 

llvm-svn: 226084

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