manipulating the diagnostics engine.

<rdar://problem/13508470>

llvm-svn: 178399

Platform select documents a -S option but doesn't accept it, now it does.

llvm-svn: 178384

rdar://problem/13536544

llvm-svn: 178367

wasn't loaded into the underlying process or
couldn't be found.

<rdar://problem/13533671>

llvm-svn: 178363

Enable tab completion for regular expression commands.

llvm-svn: 178348

<rdar://problem/13527167>

llvm-svn: 178325

“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.

<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>

llvm-svn: 178324

PC relative loads are missing disassembly comments when disassembled in a live process.

This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.

The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.

llvm-svn: 178315

By default, omit the children for a char[] and just show the string contents
Can be overridden by appropriate command-line flags

llvm-svn: 178292

llvm-svn: 178265

Be sure to take the mutex when the destructor is called in case other threads are using these lists and those other threads have the mutex locked.

llvm-svn: 178262

Partial fix for the above radar.

Call ThreadList::Clear() in the ThreadList destructor so if any other threads currently have the thread list mutex, we won't destroy the list for them while they are using it. ThreadList::Clear() takes the mutex and clears the thread list contents.

llvm-svn: 178257

- Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable.

Thanks to Greg Clayton for his review feedback.

llvm-svn: 178252

- All Linux logging channels now use a single global instance of lldb_private::Log, to handle the case of logging during process tear down.
- Also removed a single use of LogSP in FreeBSD and fixed a typo in a comment while reading through ProcessKDPLog.

Reviewed by Daniel Malea.

llvm-svn: 178242

Holding the Python lock while we call the Python C API to post-process objects returned from the OS plugins
This should avoid issues where some Python objects get invalidated while we are in the middle of processing them and we end up with an invalid Python state and a crash

llvm-svn: 178206

Protect against the case where the current inlined depth is wrong, and leads us to think we can't even get the
frame at index 0.  We should ALWAYS be able to get that.

<rdar://problem/13497571>

llvm-svn: 178205

llvm-svn: 178204

<rdar://problem/13485541>

llvm-svn: 178202

llvm-svn: 178201

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191

With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this:

{
auto lock = interpeter->AcquireInterpreterLock();
// do whatever you need to do...
} // lock will automatically be released here

This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions
Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-)

llvm-svn: 178189

- modified a comment

llvm-svn: 178178

llvm-svn: 178154

LLDB to crash.

<rdar://problem/13497915>

llvm-svn: 178115

Don't use a "uintptr_t" for the metadata key, use a "void *".  This removes all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata.

llvm-svn: 178113

The algorithm to access an item in a __NSArrayM was not reacting properly to deletions
The fix is to use a smarter formula that accounts for items shifting and the resulting notion of offsets in the table

llvm-svn: 178076

Make format uint64_t[] actually work as designed

llvm-svn: 178072

llvm-svn: 178071

llvm-svn: 178068

- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map

llvm-svn: 178057

llvm-svn: 178056

That wasn't a typo, if the short letter option is from a non-obvious source, I capitolize it in the help as an aid to memory.

llvm-svn: 178052

Our commands that end up displaying a ValueObject as part of their workflow use OptionGroupValueObjectDisplay as their currency for deciding the final representation
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose

The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion

llvm-svn: 178044

llvm-svn: 178039

We have the tag when figuring out the fully qualified name, append a suitable name for other types of tags when no name is available.

llvm-svn: 177966

Functions in "(anonymous namespace)" was causing LLDB to crash when trying to complete a type and it would also cause functions arguments to appear in wrong place in frame display when showing function arguments.

llvm-svn: 177965

Make register read and write accept $<regname> as valid.
This allows:
(lldb) reg read rbx
     rbx = 0x0000000000000000
(lldb) reg read $rbx
     rbx = 0x0000000000000000
(lldb) reg write $rbx 1
(lldb) reg read $rbx
     rbx = 0x0000000000000001

to function correctly

It is not done at the RegisterContext level because we should keep the internal API clean of this user-friendly behavior and name registers appropriately.
If this ends up being needed in more places we can reconsider.

llvm-svn: 177961

llvm-svn: 177932

C String summary is emitting "<invalid usage of pointer value as object>" for bad pointers. Now it doesn't emit anything.

llvm-svn: 177913

Only get the attach_info's user ID if the supplied user info is invalid.

llvm-svn: 177900