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

Ensure that option -Y also works for expression as it does for frame variable
Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value.

This is required for scenarios like this to work:
(lldb) p/x c
(Class) $0 = 0x0000000100adb7f8 NSObject

Previously this would say:
(lldb) p/x c
(Class) $0 = NSObject

ignoring the explicit format specifier

llvm-svn: 177893

went wrong and we tried to get layout information
that wasn't there.

<rdar://problem/13490170>

llvm-svn: 177880

<rdar://problem/12281172> 

llvm-svn: 177814

llvm-svn: 177812

llvm-svn: 177810

commands of the form 
frame variable -f c-string foo
where foo is an arbitrary pointer (e.g. void*) now do the right thing, i.e. they deref the pointer and try to get a c-string at the pointed address instead of dumping the pointer bytes as a string. the old behavior is used as a fallback if things don’t go well

llvm-svn: 177799

class symbol in the same expression, handle all
of them instead of just the first one.

<rdar://problem/13440133>

llvm-svn: 177794

Only get the script interpreter if we find scripting resources in the symbol file. This helps us avoid initializing python when it isn't needed.

llvm-svn: 177793

llvm-svn: 177792

skip every other float/double/long double as we extracted data
from a buffer.
<rdar://problem/13485062>

llvm-svn: 177779

llvm-svn: 177776

DWARFCallFrameInfo method which returns a RangeVector pre-size the
vector based on the number of entries it will be adding insted of
growing the vector as items are added.

llvm-svn: 177773

Change the AppleObjCTrampolineHandler to always run all threads when resolving the target of an ObjC method call.
Add a StopOthers method to AppleThreadPlanStepThroughObjCTrampoline, don't rely on the setting in the ThreadPlanToCallFunction, since that
gets pushed too late to determine which threads will continue.

<rdar://problem/13447638>

llvm-svn: 177691

It won't have one and it isn't needed.

llvm-svn: 177688

Clang requires them to have complete types, but
we were previously only completing them if they
were of tag or Objective-C object types.

I have implemented a method on the ASTImporter
whose job is to complete a type.  It handles not
only the cases mentioned above, but also array
and atomic types.

<rdar://problem/13446777>

llvm-svn: 177672

If we stopped but no threads had a reason for stopping, we should tell the user about it rather than continuing.

<rdar://problem/13273125> Astris thread status replies for single-core device confuse lldb; lldb resumes execution on attaching

llvm-svn: 177670

llvm-svn: 177668

This returns a vector of <file address, size> entries for all of
the functions in the module that have an eh_frame FDE.

Update ObjectFileMachO to use the eh_frame FDE function addresses if
the LC_FUNCTION_STARTS section is missing, to fill in the start 
addresses of any symbols that have been stripped from the binary.

Generally speaking, lldb works best if it knows the actual start
address of every function in a module - it's especially important
for unwinding, where lldb inspects the instructions in the prologue
of the function.  In a stripped binary, it is deprived of this
information and it reduces the quality of our unwinds and saved
register retrieval.  

Other ObjectFile users may want to use the function addresses from 
DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO
does already.
<rdar://problem/13365659> 

llvm-svn: 177624

Fixed the ValidOffsetForDataOfSize() to use simpler logic. Fixed DataExtractor::BytesLeft() to return the correct value.

llvm-svn: 177616

track the EH FDEs for the functions in a module to using a
RangeDataVector, a more light-weight data structure that only refers
to File addresses.  Makes the initial FDE scan about 3x faster, uses
less memory.
<rdar://problem/13465650> 

llvm-svn: 177585