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

llvm-svn: 178112

llvm-svn: 178085

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

llvm-svn: 178069

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

llvm-svn: 178039

llvm-svn: 178035

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

llvm-svn: 177964

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

Checking that the wrong syntax does not give a correct summary after clearing the error messages here

llvm-svn: 177949

llvm-svn: 177932

Fix the buildbot so a LLDB test doesn't fail looking for "<invalid usage of pointer value as object>".

llvm-svn: 177926

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

llvm-svn: 177913

 Don't hard code vm page size in profiling code

llvm-svn: 177907

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

Making value objects properly iterable in constructs of the form
[ x for x in value_with_children ]

This would previously cause an endless loop because lacking a proper iterator object, Python will keep calling __getitem__() with increasing values of the index until it gets an IndexError
since SBValue::GetValueForExpressionPath() supports synthetic array members, no array index will ever really cause an IndexError to be raised, hence the endless iteration

class value_iter is an implementation of __iter__() that provides a terminating iterator over a value

llvm-svn: 177885

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

<rdar://problem/13490170>

llvm-svn: 177880

llvm-svn: 177879

- Masking out SBCommandReturnObject::Printf() from the Python layer because SWIG and varargs do not get along well.
It is replaced by a Print("str") call which is equivalent to Printf("%s","str")
- Providing file-like behavior for SBStream with appropriate extension write() and flush() calls, plus documenting that these are only meant and only exist for Python
Documenting the file-like behavior on our website

llvm-svn: 177877

off the inferior process so we stand a better chance of understanding
what caused us to send a PT_KILL.
<rdar://problem/12720340> 

llvm-svn: 177817

<rdar://problem/12281172> 

llvm-svn: 177814

llvm-svn: 177812

Added a python version of the performance tests. It will be good to see if the overhead of python interferes at all with our performance readings. We can try things out with this script and see how things go.

llvm-svn: 177811

llvm-svn: 177810

- memory delta and time for: target create
- memory delta and time for: setting breakpoint at main by name
- time to launch and hit bp at main
- overall memory of target create + bp main + run to main
- ovarall time of target create + bp main + run to main

llvm-svn: 177808

Exports write() and flush() from SBCommandReturnObject to enable file-like output from Python commands.
e.g.:
def ls(debugger, command, result, internal_dict):
    print >>result,”just “some output”

will produce
(lldb) ls
just “some output
(lldb) 

llvm-svn: 177807

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