- one test case is due to llvm.org/pr16229
- other test case uses a Linux workaround for above by using os.fork() instead of subprocess module

Patch by Andy Kaylor!

llvm-svn: 183340

- specify compiler flag -stdlib=libstdc++ only if using clang (not supported in gcc)

llvm-svn: 183333

Adding data formatters for std::set, std::multiset and std::multimap for libc++
The underlying data structure is the same as std::map, so this change is very minimal and mostly consists of test cases

llvm-svn: 183323

llvm-svn: 183316

- Ensures that this container is populated once for the lifetime of lldb
--- In particular, static methods can query this data even after the first RegisterContext has been destroyed.
- Uses a singleton function to avoid global constructors.

Thanks to Greg Clayton for the suggestion!

llvm-svn: 183313

Print the lldb version at the top of the output.

llvm-svn: 183289

the link register save location being in the link register - in which case we
should iterate down the stack, not recursively try to find the lr in the current
frame over and over.

<rdar://problem/13932954>

llvm-svn: 183282

llvm-svn: 183281

<rdar://problem/14054840>

llvm-svn: 183277

Two things:
1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary
2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before

llvm-svn: 183276

If you want to define a formatter for "array of Foo of any size", ordinarily you would say

-x "Foo \[[0-9]+\]"

this checkin allows you to instead say "Foo[]" (or "Foo []") and LLDB will automatically create the regular expression and add the -x flag on your behalf

llvm-svn: 183272

Formatters for unsigned char* and const variant

llvm-svn: 183254

llvm-svn: 183253

llvm-svn: 183252

llvm-svn: 183250

Accept mach-o files with bad segments. Many core files are not created correctly and we should still be able to glean any information we can from them.

llvm-svn: 183247

LLDB API versioning
This checkin makes the LLDB API versioned
We are starting at version 1.0 and will then revise and update the API from there
Further details:
 API versioning
---------------------------------

The LLDB API is versioned independently of the LLDB source base
Our API version numbers are composed of a major and a minor number

The major number means a complete and stable revision of the API. Major numbers are compatibility breakers
(i.e. when we change the API major number, there is no promise of compatibility with the previous major version
 and we are free to remove and/or change any APIs)
Minor numbers are a work-in-progress evolution of the API. APIs will not be removed or changed across minor versions
(minors do not break compatibility). However, we can deprecate APIs in minor versions or add new APIs in minor versions
A deprecated API is supposedly going to be removed in the next major version and will generate a warning if used
APIs we add in minor versions will not be removed (at least until the following major) but they might theoretically be deprecated
in a following minor version
Users are discouraged from using the LLDB version number to test for API features and should instead use the API version checking
as discussed below

 API version checking
---------------------------------

You can (optionally) sign into an API version checking feature
To do so you need to define three macros:
LLDB_API_CHECK_VERSIONING - define to any value (or no value)
LLDB_API_MAJOR_VERSION_WANTED - which major version of the LLDB API you are targeting
LLDB_API_MINOR_VERSION_WANTED - which minor version of the LLDB API you are targeting

If these macros exist - LLDB will enable version checking of the public API

If LLDB_API_MAJOR_VERSION is not equal to LLDB_API_MAJOR_VERSION_WANTED we will immediately halt your compilation with an error
This is by design, since we do not make any promise of compatibility across major versions - if you really want to test your luck, disable the versioning altogether

If the major version test passes, you have signed up for a specific minor version of the API
Whenever we add or deprecate an API in a minor version, we will mark it with either
LLDB_API_NEW_IN_DOT_x - this API is new in LLDB .x
LLDB_API_DEPRECATED_IN_DOT_x - this API is deprecated as of .x

If you are using an API new in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then all is well, else you will get a compilation error
  This is meant to prevent you from using APIs that are newer than whatever LLDB you want to target

If you are using an API deprecated in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then you will get a compilation warning, else all is well
 This is meant to let you know that you are using an API that is deprecated and might go away

 Caveats
---------------------------------

Version checking only works on clang on OSX - you will get an error if you try to enable it on any other OS/compiler
If you want to enable version checking on other platforms, you will need to define appropriate implementations for
LLDB_API_IMPL_DEPRECATED and LLDB_API_IMPL_TOONEW and any other infrastructure your compiler needs for this purpose

We have no deprecation-as-error mode

There is no support for API versioning in Python

We reserve to use macros whose names begin with LLDB_API_ and you should not use them in your source code as they might conflict
with present or future macro names we are using to implement versioning


For API implementors:
If you need to add a new public API call, please remember to add the LLDB_API_NEW_IN_DOT_x marker in the header file
and when you are done with adding stuff, to also update LLDB_API_MINOR_VERSION
If you want to remove a function, deprecate it first, by using LLDB_API_DEPRECATED_IN_DOT_x
and when you are done with deprecating stuff, to also update LLDB_API_MINOR_VERSION
A new major version (LLDB_API_MAJOR_VERSION++) is your only chance to remove and/or change API calls
but is probably quite a big deal and you might want to consider deprecating the existing calls for a while
before doing your changes

A couple more caveats:
Currently, the lldb-tool does NOT use the version checking feature. It would be a nice future improvement to make it do that, once we have proper version checking on other OSs
APIs marked as deprecated by a comment in the source are still deprecated just that way. A good purpose for API 1.1 might be to deprecate them with appropriate markers

llvm-svn: 183244

- link libexecinfo (as libc is missing backtrace())
- enable FreeBSD-specific plugins

Patch by Ed Maste!

llvm-svn: 183233

If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, just return the current PrivateStopInfo.

Also renamed a few more places where we were using StopReason in functions that were returning StopInfo's.

<rdar://problem/14042692>

llvm-svn: 183177

- adding workaround recommended by Greg (-fno-limit-debug-info clang flag)
- filed bug llvm.org/pr16214 against Clang

llvm-svn: 183156

- ConstantDataArray is not a valid MDNode operand
- encode function-name strings in metadata by wrapping in an MDString instead

- should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/

llvm-svn: 183153

llvm-svn: 183150

llvm-svn: 183145

llvm-svn: 183140

llvm-svn: 183139

Thanks to Daniel and valgrind.

llvm-svn: 183110

llvm-svn: 183109

llvm-svn: 183058

All running threads will be detected and stopped on attach and all threads get resumed on detach.

llvm-svn: 183049

- should resolve remaining buildbot issues with debian/clang builder

llvm-svn: 183044

- as per review comment from Dimitry Andric!

llvm-svn: 183039

Patch by Ed Maste!

llvm-svn: 183038

Add 'JoinExistingSession' to XPC for root debugging.

llvm-svn: 183037

- missing #include <cstdlib> in Mangled.cpp
- missing include dirs in FreeBSD CMakeLists.txt

Patch by Ed Maste!

llvm-svn: 183032

Fixing an issue where formats would not propagate from parents to children in all cases
Details follow:
an SBValue has children and those are fetched along with their values
Now, one calls SBValue::SetFormat() on the parent
Technically, the format choices should propagate onto the children (see ValueObject::GetFormat())
But if the children values are already fetched, they won't notice the format change and won't update themselves
This commit fixes that by making ValueObject::GetValueAsCString() check if any format change intervened from the previous call to the current one
A test case is also added

llvm-svn: 183030

llvm-svn: 183024

<rdar://problem/14005311>

llvm-svn: 183022

Making sure that I get my English right by saying “0 bytes” instead

llvm-svn: 182978

command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
 - invoke reload(foo) to reload the module in Python
 - re-invoke foo.__lldb_init_module
 This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing

Usual caveats with Python imports persist. Among these:
 - if you have objects lurking around, reloading the module won't magically update them to reflect changes
 - if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work

The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not

llvm-svn: 182977

This should help us figure out issues with the NSString data formatter

llvm-svn: 182972