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

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

<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

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: 163670

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

llvm-svn: 163638

llvm-svn: 163625

it is unconditionally present now.

ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t.  use %8.8llx and cast up to uint64_t.

ObjectFile::FindPlugin ditto.

DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.

llvm-svn: 163599

Fixed an issue where if we call "Process::Destroy()" and the process is running, if we try to stop it and get "exited" back as the stop reason, we will still deliver the exited event.

llvm-svn: 163591

llvm-svn: 163590

llvm-svn: 163576

llvm-svn: 163575

Shortcut ThreadPlanStepRange::MischiefManaged - if we have pushed new plans and they are not done, then we aren't done either.

<rdar://problem/12259124>

llvm-svn: 163572

uint32_t size = ThreadList.GetSize();
for (i=0; i < size; ++i)

without grabbing the thread list mutex.

llvm-svn: 163541

run code when it didn't really need to run.

<rdar://problem/12145006>

llvm-svn: 163450

type was being completed.

llvm-svn: 163440