llvm-svn: 163638

Added "heap" command to get info on all allocations on the heap. Currently only objective C objects are supported since they are easy to detect.

llvm-svn: 163637

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

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

truncated during install-headers.

<rdar://problem/12268130>

llvm-svn: 163559

llvm-svn: 163543

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

without grabbing the thread list mutex.

llvm-svn: 163541

Playing around with "objc_refs" over the weekend and improved it to work on a large ObjC program without running into expression timeouts. Now we get a full list of ObjC classes using a runtime function and then qsort the result. Also added code that can count all instances of each ObjC on the heap and also the total byte sizes for the object allocations.

llvm-svn: 163520

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

<rdar://problem/12145006>

llvm-svn: 163450

llvm-svn: 163441

type was being completed.

llvm-svn: 163440

Fiddle with the heuristic about where to set the stop point in a nested inline stack when we get there by breakpoint.  If we hit a user breakpoint, I set the stop point to the bottom-most frame 'cause that's what we did before.

<rdar://problem/12258999> Setting breakpoint in always inline function is stopping in function above it

llvm-svn: 163439

llvm-svn: 163436

Make file + line breakpoints even more efficient by using our SearchFilter objects correctly now that we sometimes don't check for inlined breakpoints.

llvm-svn: 163435

llvm-svn: 163433

In GetFramesUpTo, don't adjust the number of frames for the inlined depth if the number of frames in UINT32_MAX.

llvm-svn: 163432

llvm-svn: 163421

Train LLDB to deal with bad linker N_SO entries that point to our source files for debug map + DWARF in .o file debugging.

llvm-svn: 163417

The attached patch fixes a problem with performing an attach from the SBTarget API on Linux (and other systems that use ProcessPOSIX).
 
When Process::Attach was called from SBTarget, it resulted in a call to a form of the DoAttachWithID function that wasn't implemented in ProcessPOSIX, and so it fell back to the default implementation (which just returns an error).  It didn't seem necessary to use the attach_info parameter for this case, so I just implemented it as a call to the simpler version of the function.
 
In debugging this problem, I also found that SBTarget wasn't checking the return value from the Attach call, causing it to hang when the attach fails.

llvm-svn: 163399

The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system.
 
Making this work required two basic changes:
 
1)      Getting lldb to report that it could debug 32-bit processes
2)      Changing an assumption about how ptrace works when debugging cross-platform
 
For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms.  It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure.
 
For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size.  However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant."  I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written.

llvm-svn: 163398

llvm-svn: 163366

llvm-svn: 163365

llvm-svn: 163352

llvm-svn: 163351

llvm-svn: 163341

llvm-svn: 163340

llvm-svn: 163332

only accept the first matching type based on lldb's sizeofs.
<rdar://problem/12222109>

llvm-svn: 163285

which can conflict with accurate crash reporting
in multithreaded contexts.

llvm-svn: 163282

Fixed an issue where we didn't parse N_SO stab pairs where the first N_SO was a relative path.

llvm-svn: 163259

llvm-svn: 163250

When the vendor and OS are not specified in a triple, only let unspecified vendor and OS fields matchs for the current host platform.

llvm-svn: 163248

llvm-svn: 163246

llvm-svn: 163245