| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 167636
|
| |
|
|
|
|
| |
<rdar://problem/12090979>
llvm-svn: 167601
|
| |
|
|
|
|
| |
ModuleList as part of the callbacks, and not copying the notifier as part of copy constructing and assigning
llvm-svn: 167592
|
| |
|
|
|
|
|
|
| |
lacking the dSYM bundle, or if the bundle has no Pythonic resources whatsoever
Solving an issue where "command script import" would fail to pick the file indicated by the user as a result of something with the same name being in an earlier position in sys.path
llvm-svn: 167570
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
- the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
- if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine
llvm-svn: 167569
|
| |
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule
where it assumed that a kernel had been found in memory, when that may not be
the case when we're attaching to a device early in the boot process.
<rdar://problem/12638140>
llvm-svn: 167564
|
| |
|
|
|
|
|
|
|
|
| |
<rdar://problem/12153915> (partial fix)
Remove an assert and place an error message instead so we don't crash when we run into a type tag that we don't recognize. We will now emit a warning so that hopefully we can get a bug report that has example code that shows what we are missing.
Also fixed a case when trying to unique one type to another where we would confuse concrete instances of methods with their definitions and end up not correctly registering the types.
llvm-svn: 167557
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
something like
x/9i
we actually calculated the size of 9 instructions. Then we multiplied it by the count again
to get the total amount we should fetch, so we thought 9 x86_64 instructions took over 1K
to fetch...
<rdar://problem/12649027>
llvm-svn: 167520
|
| |
|
|
|
|
|
|
|
|
|
| |
Also fixed a bug where the Objective-C runtime
would not properly report that it found a class if
(a) it had to build the ObjCInterfaceDecl for the
class and (b) logging was enabled.
<rdar://problem/12641180>
llvm-svn: 167516
|
| |
|
|
| |
llvm-svn: 167473
|
| |
|
|
| |
llvm-svn: 167471
|
| |
|
|
|
|
|
|
| |
inlined subroutine ranges.
<rdar://problem/12588579>
llvm-svn: 167430
|
| |
|
|
|
|
|
|
| |
Unnamed bitfields cause struct layout problems
Synthesize unnamed bitfields when required. Most compilers don't mention unnamed bitfields in the DWARF, so we need to create them to keep clang happy with the types we create from the DWARF. We currently can't do this for ObjC since the DW_AT_bit_offset value for any direct ivars of ObjC classes as the values for these attributes are bogus. A bug has been filed on Clang to fix this, and another bug has been filed on LLDB to make sure we fix the DWARF parser once the clang fix is in by looking the the DW_AT_producer in the compile unit attributes and finding the compiler version and only enabling it for newer versions of clang.
llvm-svn: 167424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The operator== method is a synonym for IsExactMatch().
The essential difference between these two is that IsCompatibleMatch()
will say that armv7 and armv7s are compatible and return true.
IsExactMatch() will say that armv7 and armv7s are not a match.
An armv7s cpu can run either generic armv7 binaries or armv7s binaries
(the latter being tuned for it). When we're picking the slice of a
universal Mach-O file to load in an armv7s Target, we need to be able to
first look for an exact cpu subtype match (armv7s == armv7s) and failing
that, looking for a slice with a compatible architecture.
Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact
match of the cpu type, falling back to a compatible match if necessary.
<rdar://problem/12593515>
llvm-svn: 167365
|
| |
|
|
|
|
|
|
|
|
|
| |
whether the rhs file was resolved or not by comparing
the resolved version of the rhs FileSpec's directory name with the lhs FileSpec's directory name. We really meant to compare it
with the rhs FileSpec's directory name...
<rdar://problem/12438838>
llvm-svn: 167349
|
| |
|
|
|
|
| |
a process by changing the documentation string.
llvm-svn: 167343
|
| |
|
|
| |
llvm-svn: 167342
|
| |
|
|
|
|
|
| |
variables for guard variables because the current
class or method named contained the letters "GV".
llvm-svn: 167327
|
| |
|
|
| |
llvm-svn: 167314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the runtime if we have complete debug information
for a class.
Also made the Objective-C language runtime return
NULL when asked for the complete debug information
(i.e., information from DWARF, not information from
the runtime) if that information isn't present. It
used to return a non-authoritative version, which
made it hard for clients to determine whether
complete debug information was available.
<rdar://problem/12608895>
llvm-svn: 167299
|
| |
|
|
|
|
|
|
|
|
|
| |
statements instead of a switch for the size of the floating
point types; some architectures sizeof double and sizeof long
double are the same and that's invalid in a switch.
Fix the LLDB_DISABLE_PYTHON ifdef block in FormatManager::LoadObjCFormatters
so it builds on arm again.
llvm-svn: 167263
|
| |
|
|
|
|
| |
LLDB now provides base class offsets (virtual and non virtual) to Clang's record layout. We previously were told this wasn't necessary, but it is when pragma pack gets involved.
llvm-svn: 167262
|
| |
|
|
|
|
| |
lldb-platform to not be able to link.
llvm-svn: 167253
|
| |
|
|
| |
llvm-svn: 167242
|
| |
|
|
| |
llvm-svn: 167236
|
| |
|
|
|
|
|
|
| |
ProcessGDBRemote, but we haven't managed to shut down the async thread. That causes the ProcessGDBRemote::AsyncThread to crash when it wakes up. So I changed StartAsyncThread and StopAsyncThread to be callable multiple times (only the first one does anything) so that we can just shut it down unequivocally in the ProcessGDBRemote destructor.
<rdar://problem/12602981>
llvm-svn: 167197
|
| |
|
|
| |
llvm-svn: 167171
|
| |
|
|
| |
llvm-svn: 167168
|
| |
|
|
|
|
| |
argument to be passed. I got rid of the default args so we don't run into this.
llvm-svn: 167167
|
| |
|
|
|
|
| |
incorrectly following an if statement. There actually isn't a need for the if statement, so it was removed.
llvm-svn: 167160
|
| |
|
|
|
|
|
|
| |
that confused external clients.
<rdar://problem/12599528>
llvm-svn: 167097
|
| |
|
|
|
|
|
|
|
| |
CXXMethodDecl but tried to manipulate it
anyway.
<rdar://problem/12601996>
llvm-svn: 167095
|
| |
|
|
|
|
|
|
| |
EmulateInstructionARM::GetThumbOpcodeForInstruction
so it is recognized correctly. The second patch needed for <rdar://problem/10652166>.
llvm-svn: 167094
|
| |
|
|
|
|
|
|
|
|
|
| |
script import", such that the error message for the exception becomes the error for the entire import operation
and silence the backtrace printout
In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly
instead of having the default behavior
llvm-svn: 167067
|
| |
|
|
|
|
| |
RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
|
| |
|
|
| |
llvm-svn: 167065
|
| |
|
|
|
|
|
|
|
|
| |
methods of
the containing class so that direct ivar access will work in the expression parser.
<rdar://problem/9797999>
llvm-svn: 167061
|
| |
|
|
| |
llvm-svn: 167060
|
| |
|
|
|
|
|
|
|
| |
"~rc" via getpwnam() instead of doing tilde expansion and doing soft-link
dereferencing via realpath() - if we're pointing to a softlink, leave it
as-is.
<rdar://problem/12597698>
llvm-svn: 167052
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The attached patch adds eValueTypeVector to lldb_private::Value. The nested struct Vector is patterned after RegisterValue::m_data.buffer. This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue. Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py. In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully. On the other hand, the output is glaringly empty:
runCmd: expr $xmm0
output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
Expecting sub string: vector_type
Matched
llvm-svn: 167033
|
| |
|
|
|
|
| |
multiply-nested inlined code.
llvm-svn: 167028
|
| |
|
|
|
|
| |
This patch switches support on Linux from JIT to MCJIT.
llvm-svn: 167026
|
| |
|
|
| |
llvm-svn: 167025
|
| |
|
|
| |
llvm-svn: 167024
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
bool
SBType::IsFunctionType ();
lldb::SBType
SBType::GetFunctionReturnType ();
lldb::SBTypeList
SBType::GetFunctionArgumentTypes ();
llvm-svn: 167023
|
| |
|
|
| |
llvm-svn: 167019
|
| |
|
|
|
|
|
|
|
| |
does not automatically initialize the script interpreter in order to transfer its output file handle to it
This should delay initialization of Python until strictly necessary and speed-up debugger startup
Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes
llvm-svn: 166967
|
| |
|
|
|
|
|
|
| |
I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad.
To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen.
llvm-svn: 166964
|
| |
|
|
| |
llvm-svn: 166959
|
| |
|
|
| |
llvm-svn: 166950
|