Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.

<rdar://problem/11319574>
<rdar://problem/9329275>

llvm-svn: 176392

  - made sure we tell Clang not to try to
    complete the type since it can't be
    completed from its origin any more; and

  - fixed a silly bug where we tried to
    forget about the original decl's origins
    rather than the deported decl's origin.

These produced some crashes in ptr_refs,
especially under libgmalloc.

<rdar://problem/13256150>

llvm-svn: 176233

llvm-svn: 176206

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

llvm-svn: 175953

llvm-svn: 175829

On x86-64 platforms, the small code model assumes that code will be loaded below the 2GB boundary.  With the static relocation model, the fact that the expression code is initially loaded (in the LLDB debugger address space) above that boundary causes problems.  Switching to the JITDefault code model causes the large code model to be used for 64-bit targets and small code model of 32-bit targets.

llvm-svn: 175828

<rdar://problem/13254824>

llvm-svn: 175806

- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified

Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion

Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!

llvm-svn: 175795

work on i386.  Now we let the JIT emit SSE/SSE2
instructions on i386.

<rdar://problem/13240476>

llvm-svn: 175700

llvm-svn: 175671

- removed an unnecessary variable
- fixed an issue where we sometimes
  wrote too much data into a buffer
- made the recognition of variables
  as "this" a little more conservative

<rdar://problem/13216268>

llvm-svn: 175318

llvm-svn: 175213

llvm-svn: 175108

Parse objective C information as efficiently as possible and without taking dangerous runtime locks.

Reworked the way objective C information is parsed by:
1 - don't read all class names up front, this is about 500K of data with names
2 - add a 32 bit hash map that maps a hash of a name to the Class pointer (isa)
3 - Improved name lookups by using the new hash map
4 - split up reading the objc runtime info into dynamic and shared cache since the shared cache only needs to be read once.
5 - When reading all isa values, also get the 32 bit hash instead of the name
6 - Read names lazily now that we don't need all names up front
7 - Allow the hash maps to not be there and still have this function correctly

There is dead code in here with all of the various methods I tried. I want to check this in first to not lose any of it in case we need to revert to any of the extra code. I will promptly cleanup and commit again.

llvm-svn: 175101

builtins.

<rdar://problem/13204027>

llvm-svn: 175091

changing the ClangASTSource to return a bool instead
of returning a list of results.  Our testsuite mostly
works with this change, but some minor issues may
remain both on LLDB's side and on Clang's side.

llvm-svn: 174949

up variables in the current stack frame to avoid
mutual recursion between the expression parser
and the synthetic child providers.  Variables
should only be looked up in a very simple way,
using no synthetic anything.

<rdar://problem/13173454>

llvm-svn: 174947

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug 
session.

<rdar://problem/12993641>

llvm-svn: 174793

llvm-svn: 174579

be "signed char" not "int".

<rdar://problem/13131126>

llvm-svn: 174209

support reporting "this" as a templated class.  The
expression parser wraps expressions in C++ methods
as methods with the signature

$__lldb_class::$__lldb_expr(...)

and previously responded to clang's queries about
$__lldb_class with the type of *this.  This didn't
work if *this was a ClassTemplateSpecializationDecl
because ClassTemplateSpecializationDecls can't be
the result of simple name queries.

Instead what we do now is respond that $__lldb_class
is a typedef and that the target of the typedef is
the (potentially templated) type of *this.  That is
much more robust.

Thanks to John McCall for key insights.

<rdar://problem/10987183>

llvm-svn: 174153

Add "thread return -x" to unwind the innermost user called expression (if you happen to have stopped in it due to a crash.)
Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x".

rdar://problem/13110464

llvm-svn: 174095

wchar_t causes problem with certain compilers. Removing it for now.

llvm-svn: 173823

llvm-svn: 173731

Always define types from stdint.h so they are always available for use in expressions no matter what debug info you have. Types added are:

int8_t
uint8_t
int16_t
uint16_t
int32_t
uint32_t
int64_t
uint64_t
intptr_t
uintptr_t
size_t
ptrdiff_t
whar_t

llvm-svn: 173724

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463

Avoids an error about an ambiguous constructor
call.

llvm-svn: 173118

in an Objective-C class method.  Before, errors
of the form

error: cannot find interface declaration for '$__lldb_objc_class'

would appear when running any expression when
the current frame is a block that captures 'self'
from an Objective-C class method.

<rdar://problem/12905561>

llvm-svn: 172880

DW_AT_const_value instead of a location.  Also
added a testcase covering "frame variable," "expr"
using the IR interpreter, and "expr" using the
LLVM JIT.

<rdar://problem/12978195>

llvm-svn: 172848

handling multiple clients.  However, occasionally an
expression must be run in the service of another
expression, and in this case two parsers need to access
the same list of persistent variables.

To allow this, persistent variables now provide state
for multiple parsers, and parsers must allocate, access,
and deallocate this state by providing their own ID
(at the moment, simply the value of the "this" pointer).

<rdar://problem/12914539>

llvm-svn: 172573

Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint.  For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.  
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint.  We were recursing
and crashing.  Now we just stop without calling the second command.

<rdar://problem/12986644>
<rdar://problem/9119325>

llvm-svn: 172503

JIT it again.

llvm-svn: 172477

<rdar://problem/12978619>

llvm-svn: 172013

llvm-svn: 171381

migration in r171366.

I don't know anything about lldb, but a force run of the build bot indicated it
would need this patch. I'll try to watch the build bot to get it green.

llvm-svn: 171374

the IR interpreter.

<rdar://problem/12921700>

llvm-svn: 170934

The results from Clang name lookups changed to
be ArrayRefs, so I had to change the way we
check for the presence of a result and the way
we iterate across results.

llvm-svn: 170927

for reporting class types from Objective-C runtime
class symbols.  Instead, LLDB now queries the 
Objective-C runtime for class types.

We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to 
prevent regressions when calling class methods in
the V1 runtime.

Other components of this fix include:

- We search the Objective-C runtime in a few more
  places.

- We enable enumeration of all members of
  Objective-C classes, which Clang does in certain
  circumstances.

- SBTarget::FindFirstType and SBTarget::FindTypes
  now query the Objective-C runtime as needed.

- I fixed several test cases.

<rdar://problem/12885034>

llvm-svn: 170601

the AST result synthesizer's logging.

<rdar://problem/12889053>

llvm-svn: 170396

Fix a parser_type to get created with the right AST, and also make variables made from symbols to not be "void * const", but just "void *".

llvm-svn: 170165