| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
char[]
llvm-svn: 178295
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
item-not-in-cluster asserts
llvm-svn: 178265
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
target processor.
- 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
|
| |
|
|
| |
llvm-svn: 178251
|
| |
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
| |
- the ".app" would be treated as the app bundle final characters
and the SpringBoard launch would fail.
<rdar://problem/13258935>
llvm-svn: 178209
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
ThreadPlanCallFunction isn't valid.
llvm-svn: 178203
|
| |
|
|
|
|
| |
<rdar://problem/13485541>
llvm-svn: 178202
|
| |
|
|
|
|
| |
made for some reason.
llvm-svn: 178201
|
| |
|
|
|
|
| |
generating spurious over-completion warning flags
llvm-svn: 178192
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Cleaned up some paths.
llvm-svn: 178177
|
| |
|
|
| |
llvm-svn: 178176
|
| |
|
|
|
|
| |
Enhance automated testing to include evaluating function calls.
llvm-svn: 178175
|
| |
|
|
| |
llvm-svn: 178154
|
| |
|
|
|
|
|
|
| |
LLDB to crash.
<rdar://problem/13497915>
llvm-svn: 178115
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
dependencies.
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
|
| |
|
|
|
|
| |
object” logging is on.
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
|
| |
|
|
|
|
| |
I capitolize it in the help as an aid to memory.
llvm-svn: 178052
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
used.
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
|
| |
|
|
|
|
| |
clearing the error messages here
llvm-svn: 177949
|
| |
|
|
|
|
| |
SBTarget API.
llvm-svn: 177932
|
| |
|
|
|
|
| |
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
|