Age | Commit message (Collapse) | Author |
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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 :-)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- modified a comment
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178178 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Cleaned up some paths.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178177 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Enhance automated testing to include evaluating function calls.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178175 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178154 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LLDB to crash.
<rdar://problem/13497915>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178085 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Make format uint64_t[] actually work as designed
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178072 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178070 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
object” logging is on.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I capitolize it in the help as an aid to memory.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178052 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178044 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
used.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178035 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177961 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
clearing the error messages here
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177949 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SBTarget API.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177932 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer value as object>".
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177926 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C String summary is emitting "<invalid usage of pointer value as object>" for bad pointers. Now it doesn't emit anything.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177913 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Don't hard code vm page size in profiling code
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Only get the attach_info's user ID if the supplied user info is invalid.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177900 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
went wrong and we tried to get layout information
that wasn't there.
<rdar://problem/13490170>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177880 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
out why
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177879 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
off the inferior process so we stand a better chance of understanding
what caused us to send a PT_KILL.
<rdar://problem/12720340>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/12281172>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177812 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the overhead of python interferes at all with our performance readings. We can try things out with this script and see how things go.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177811 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177807 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class symbol in the same expression, handle all
of them instead of just the first one.
<rdar://problem/13440133>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177794 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
file. This helps us avoid initializing python when it isn't needed.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177793 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177792 91177308-0d34-0410-b5e6-96231b3b80d8
|