has more than one function with a body.  This
prevents declarations e.g. of blocks from being
passed to the IRInterpreter; they must pass
through to the JIT.

<rdar://problem/14180236>

llvm-svn: 185057

llvm-svn: 185055

correctly.  We have been getting lucky since most
expressions generate only one section (or the first
code section contains all the code), but sometimes
it actually matters.

<rdar://problem/14180236>

llvm-svn: 185054

bother checking if a region is safe to use.  In
cases where regions need to be synthesized rather
than properly allocated, the memory reads required
to determine whether the area is used are

- insufficient, because intermediate locations
  could be in use, and

- unsafe, because on some platforms reading from
  memory can trigger events.

All this only makes a difference on platforms
where memory allocation in the target is impossible.
Behavior on platforms where it is possible should
stay the same.

<rdar://problem/14023970>

llvm-svn: 185046

llvm-svn: 185010

llvm-svn: 184954

Host::GetOSVersion's caller already sets it to UINT32_MAX to determine
which version number components are set.

llvm-svn: 184953

llvm-svn: 184948

Remove the #define USE_CACHE since the formatters cache has been operational for a while now and has not caused issues that warrant disabling it
Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users

llvm-svn: 184900

"command source" was not properly setting the stop-on-error option

llvm-svn: 184899

The argument to -w (--category) in type * list is a regular expression
This caused unhappiness with the gnu-libstdc++ category because of the double ++

Now we check for exact textual match as-well-as regexp matching

llvm-svn: 184898

The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened

This checkin changes that:
- SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string
- script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed

If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior

llvm-svn: 184893

the target of a typedef when asked for a typedef.

llvm-svn: 184886

Release strings are of the form 9.1-RELEASE-p3 or 10.0-CURRENT.

llvm-svn: 184876

It is defined on recent FreeBSD versions, so must not be mutually
exclusive with an #elif FreeBSD block.

Patch submitted by Robert Millan.

Fixes PR#16447.

llvm-svn: 184867

llvm-svn: 184854

llvm-svn: 184850

print to standard output as part of normal
operation.

<rdar://problem/14247606>

llvm-svn: 184797

Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first.

Reviewed by Greg

llvm-svn: 184769

doesn't return anything; that's great.

We should probably also return rather than
trying to access the nonexistent return value.

<rdar://problem/14009519>

llvm-svn: 184765

- Sort functions in the same order
- Match whitespace
- Remove commetned out code
- Make filename in comments match filename

llvm-svn: 184746

llvm-svn: 184745

llvm-svn: 184744

Akin to r181712 (88e529b7) of Linux/ProcessMonitor.cpp

llvm-svn: 184742

Revision r147613 (2341d35) renamed this file with s/Linux/POSIX/, but
header guards and comments were not updated to match.

llvm-svn: 184741

Using offsetof to an item within an array is an extension so mark it as such to avoid compiler warnings.

llvm-svn: 184738

llvm-svn: 184737

<rdar://problem/14147303>

llvm-svn: 184622

llvm-svn: 184619

Remove old GetNextThreadIndexID() from lldb

llvm-svn: 184600

I added scan type to ‘qGetProfileData’ previously but forgot to update the check to be a substring search.

llvm-svn: 184588

- %N = show the name of the variable
- %> = show the expression path of the variable

llvm-svn: 184502

In thread and frame format strings, it is now allowed to use Python functions to generate part or all of the output text
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as

def FooFunction(Object,unused)

where object is of the respective SB-type (SBTarget for target.script, ... and so on)

This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB

llvm-svn: 184500

to nil objects, it won't work anyway.

llvm-svn: 184474

dematerialization of registers that caused
conditional breakpoint expressions not to
work properly.  Also added a testcase.

<rdar://problem/14129252>

llvm-svn: 184451

llvm-svn: 184390

Unique types a bit more using the clang type to make sure we don't get multiple copies of the same type due to the debug info having multiple types that get uniqued.

llvm-svn: 184388

The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.

llvm-svn: 184364

llvm-svn: 184342

Fixing a bug with the NSString data formatter where some strings would be truncated

llvm-svn: 184336