Making ClangExpression hold on to a WP to the Process instead of a SP. This fix should enable us to have per-process maps of ClangExpressions without fear of keeping the process alive forever

llvm-svn: 164082

llvm-svn: 164081

llvm-svn: 164050

stomped on.

llvm-svn: 164049

llvm-svn: 164048

building on no-Python systems again.

llvm-svn: 163961

the dynamic and static runtime class tables to
construct our isa table.  This is putting the runtime
in contact with unrealized classes, which we need
to deal with in order to get accurate information.
That's the next piece of work.

<rdar://problem/10986023>

llvm-svn: 163957

Fixing a potential crasher where the new C++ synthetic children can return a NULL FrontEnd and cause LLDB to crash. This patch introduces a dummy front-end which the ValueObjectSynthetic can use lacking a real FrontEnd

llvm-svn: 163946

<rdar://problem/12304255>

llvm-svn: 163943

llvm-svn: 163938

llvm-svn: 163937

llvm-svn: 163936

SBThread::StepOverUntil should run all threads.  It is running to breakpoints, so running one thread is likely to cause the target to stall.

llvm-svn: 163924

support watchpoints on globals.

<rdar://problem/12297238>

llvm-svn: 163913

This may (but shouldn't) break Linux (but I tested and it still worked on FreeBSD).

The same shell scripts are now used on Xcode and Makefiles, for generating
the SWIG bindings.
Some compatibility fixes were applied, too (python path, bash-isms, etc).

llvm-svn: 163912

Make the flags part of configure and make invocations, for now.

llvm-svn: 163911

When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name.

llvm-svn: 163868

llvm-svn: 163867

<rdar://problem/12293231>

llvm-svn: 163864

them in one place rather than having them replicated
across all the potential function wrappers.

<rdar://problem/12293880>

llvm-svn: 163857

llvm-svn: 163852

llvm-svn: 163851

"target image lookup" a bit better
documented by indicating that it takes
symbols OR functions.

<rdar://problem/12281325>

llvm-svn: 163839

Making sure to create the count attribute in synthetic children providers for libcxx at the right time

llvm-svn: 163823

<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray

llvm-svn: 163818

llvm-svn: 163800

llvm-svn: 163773

llvm-svn: 163742

llvm-svn: 163725

llvm-svn: 163712

Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.

llvm-svn: 163676

llvm-svn: 163675

Added some documentation and an accessor for the target with an explanation of why to not use "lldb.target".

llvm-svn: 163671

llvm-svn: 163670

llvm-svn: 163669

and deleted classes.

llvm-svn: 163652

information from the Objective-C runtime.

This patch takes the old AppleObjCSymbolVendor and
replaces it with an AppleObjCTypeVendor, which is
much more lightweight.  Specifically, the SymbolVendor
needs to pretend that there is a backing symbol file
for the Types it vends, whereas a TypeVendor only
vends bare ClangASTTypes.  These ClangASTTypes only
need to exist in an ASTContext.

The ClangASTSource now falls back to the runtime's
TypeVendor (if one exists) if the debug information
doesn't find a complete type for a particular
Objective-C interface.  The runtime's TypeVendor
maintains an ASTContext full of types it knows about,
and re-uses the ISA-based type query information used
by the ValueObjects.

Currently, the runtime's TypeVendor doesn't provide
useful answers because we haven't yet implemented a
way to iterate across all ISAs contained in the target
process's runtime.  That's the next step.

llvm-svn: 163651

llvm-svn: 163641

llvm-svn: 163640

Unbreaks the build on FreeBSD

People that are using Linux: if you have any problems with this patch
please let me know, and tell us how you are compiling lldb with the
makefiles.

llvm-svn: 163639