Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure.
llvm-svn: 169465
of the "self"/"this" pointer for the current stack
frame before wrapping expressions in C++ or
Objective-C methods. This works around bad debug
info where the compiler emits a "this" or "self"
but doesn't give any way to find its location.
<rdar://problem/12809985>
llvm-svn: 169461
- Removed the BitfieldMap class because it is unnecessary.
We now just track the most recently added field.
- Moved the code that calculates bitfield widths so it
can also be used to determine whether it's necessary
to insert anonymous fields.
- Simplified the anonymous field calculation code into
three cases (two of which are resolved identically).
- Beefed up the bitfield testcase.
llvm-svn: 169449
I filed this to track the fix:
<rdar://problem/12817918> Recent i386 ABI changes break the i386 test suite because stack backtracing is busted when stopped in trampolines
llvm-svn: 169409
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
these are the *non-volatile* registers on Darwin/i386, not the
volatile registers.
Recognize the sp, pc, fp generic reg names as well.
llvm-svn: 169316
type of an Objective-C selector, don't bother
making the expression parser resolve it all over
again. Just send the message straight to the
object pointer as if it were an id, and cast the
result.
<rdar://problem/12799087>
llvm-svn: 169300
Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects.
llvm-svn: 169205
Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.
This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value
llvm-svn: 169189
- use const char* instead of char* as needed in ObjC language runtime plugin
- use int to iterate through enum (operator++ on enum not defined)
- use initializer list instead of inline initialization of const field
llvm-svn: 169185
that kexts were newly added.
The Darwin userland dynamic loader provides lldb with a list of
newly-added or newly-removed binaries but in the kernel case we
only know that something has changed. DynamicLoaderDarwinKernel
really needs to maintain its own persistent list of kexts that
it has been notified about (most importantly, it will not detect
kext unlods) but for now we'll at least avoid re-adding an already
present kext.
<rdar://problem/12658487>, <rdar://problem/12658487>
llvm-svn: 169082
For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file:
(lldb) target create --symfile /tmp/a.dSYM /usr/bin/a
Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer.
llvm-svn: 169023
Emit an error when using "target modules add PATH" where PATH points to a debug info only (dSYM) file.
Also added a "--uuid" option for "target modules add --uuid UUID" to locate and load a module by UUID if the host supports it.
llvm-svn: 168949
Prevent async and sync calls to get profile data from stomping on each other.
At the same time, don't use '$' as end delimiter per chunk of profile data.
llvm-svn: 168948
Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function.
llvm-svn: 168845
versions of UnknownAnyTy for ObjectiveC value types.
<unknown type>* makes no sense and can cause the
parser to behave very oddly.
<rdar://problem/12518999>
llvm-svn: 168844
the frame and then getting the run lock. Which means that our frame could have gotten
invalidated by stopping between the time we got the frame and assured the the target was
stopped. Now we get the run lock first, and THEN resolve the underlying frame object.
<rdar://problem/12621607>
llvm-svn: 168838
Simplify the logging on ObjectFile::~ObjectFile() to not access an classes above the object file (like the module) so we don't crash when logging object lifetimes. The log message contains the "this" pointer value which can be matched up with the constructor log.
llvm-svn: 168754
DebugClang builds of LLDB to build a properly
codesigned debugserver. I did this by adding
a DebugClang configuration to debugserver that's
just a clone of the Debug configuration.
llvm-svn: 168746
Make sure that ValueObjectDynamicValue clears itself when no dynamic type information can be found
This behavior was supposed to be already happening (as per the comment lines)
llvm-svn: 168743
Allow the expression parser to see more than just data symbols. We now accept any symbol that has an address. We take precautions to only accept symbols by their mangled or demangled names only if the demangled name was not synthesized. If the demangled name is synthesized, then we now mark symbols accordingly and only compare against the mangled original name.
llvm-svn: 168668
- use lldb settings command instead of os.environ
- use dyldPath fixture variable instead of hardcoding LD_LIBRARY_PATH
- add tear-down hook to restore environment after testcase is run
llvm-svn: 168613
- use lldb 'settings' command to help testcase find shared library
- pull up dyldPath variable from TestLoadUnload.py to fixture base class (applicable in multiple cases)
llvm-svn: 168612
- Handle EINVAL return code from ptrace(GETSIGINFO, ...): not an error, but 'group-stop' state on Linux
- propagate SIGSTOP to inferior in above case
- this commit resolves the failure in expression_command/timeout testcase
Thanks to Sean Callanan & Matt Kopec for helping debug this problem
llvm-svn: 168523
- missing includes in cpp test programs
- mismatched dwarf/dsym test cases
- make "com.apple.main-thread" expected string conditional on darwin platform
llvm-svn: 168452
allowed volatile registers to be returned up the stack. That leads
to unexpected/incorrect values provided to the user and we need to
avoid that.
<rdar://problem/12714247>
llvm-svn: 168123
Fixed an issue where lldb was setting breakpoints on too many methods when a partial function name with namespaces or class qualifiers was used. For example setting a breakpoint of "Foo::dealloc" was accidentally settings breakpoints on all objective C functions whose selector was "dealloc"...
llvm-svn: 168053
expressions that refer to ivars will not work because Clang
emits IR that refers to them to get the ivar offsets.
However, it is possible to search the runtime for these values.
I have added support for reading the relevant tables to the
Objective-C runtime, and extended ClangExpressionDeclMap to
query that information if and only if it doesn't find the symbols
in the binary.
Also added a testcase.
<rdar://problem/12628122>
llvm-svn: 168018
When uniquing classes against one another we can't depend on any or all of the artificial functions (default ctor, dtor, copy ctor, move ctor, etc) being in each definition. Now we treat those separately and handle those to the best of our ability.
llvm-svn: 167752
GCD queue names of threads to
ProcessGDBRemote::GetDispatchQueueNameForThread()
May need tweaking once this version is rolled out but visual
inspection looks fine.
<rdar://problem/12333100>
llvm-svn: 167667
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
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
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
- make sure to delet the .cer file on the desktop
- added section that describes what to do when you re-install a new OS where
you still have an old code signing certificate around.
llvm-svn: 167389
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
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
Jason Molenda