- introduce new variable ARCHFLAG in make/Makefile.rules to switch between "-arch" on Mac and "-m" everywhere else
- update testcase makefiles to use LD_EXTRAS instead of LDFLAGS (the former interacts with Makefile.rules badly)
- special treatment for gcc 4.6: replace "-std=c++11" with "-std=c++0x" as the former is not handled correctly
- remove hardcoded "-arch" from test Makefile
This patch should not have any effect on lldb on Mac OS X.
llvm-svn: 173402
- PR 15038: missing wide char support on Linux
- PR 14600 - Exception state registers not supported on Linux
- PR 15039: SBProcess.GetSTDOUT() returns an empty buffer
- PR 15037: stop-hooks sometimes fail to fire on Linux
llvm-svn: 173363
Extending ValueObjectDynamicValue so that it stores a TypeAndOrName instead of a TypeSP.
This change allows us to reflect the notion that a ValueObject can have a dynamic type for which we have no debug information.
Previously, we would coalesce that to the static type of the object, potentially losing relevant information or even getting it wrong.
This fix ensures we can correctly report the class name for Cocoa objects whose types are hidden classes that we know nothing about (e.g. __NSArrayI for immutable arrays).
As a side effect, our --show-types argument to frame variable no longer needs to append custom dynamic type information.
llvm-svn: 173216
in an Objective-C class method. Before, errors
of the form
error: cannot find interface declaration for '$__lldb_objc_class'
would appear when running any expression when
the current frame is a block that captures 'self'
from an Objective-C class method.
<rdar://problem/12905561>
llvm-svn: 172880
DW_AT_const_value instead of a location. Also
added a testcase covering "frame variable," "expr"
using the IR interpreter, and "expr" using the
LLVM JIT.
<rdar://problem/12978195>
llvm-svn: 172848
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
Providing a data formatter for libc++ std::wstring
In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited
Also, providing a new API on the ValueObject to navigate a hierarchy by index-path
Lastly, an appropriate test case is included
llvm-svn: 172282
Providing data formatters for char16_t* and char32_t* C++11-style Unicode strings
Using this chance to refactor the UTF data reader used for data formatters for added generality
Added a relevant test case
llvm-svn: 172119
Enabling support for the wchar_t type.
Without the proper language option setup, clang's ASTContexts will be configured to have wchar_t == int
This patch enables the correct options to make sure that we report wchar_t as itself
Added a test case to make sure we do not regress
llvm-svn: 172038
Adding useful formatting options to the expression (expr) command.
As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously
These options do not apply to print, p or po because these are aliased to not take any options.
In order to use them, use expression or expr.
llvm-svn: 171993
Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file.
Also fixed issues in the test suite that arose after fixing the bug.
Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option.
llvm-svn: 171816
- now prints the correct PYTHONPATH
- update dotest.py to use lldb -P result correctly
- resolves TestPublicAPIHeaders test failure (on Linux)
llvm-svn: 171558
Not all of the expected instructions were being generated for the function being disassembled on x86-64-based Linux. It had no push, pop or leave.
llvm-svn: 170818
Note that the test actually fails before reaching the assertion described in that bug, but the failure is a trivial matter of adding OS-conditional expected stop reason strings (as noted by new comments in this patch). However, with the stop reason strings changed, the test fails for the more substantial reason noted in bugzilla 14662.
llvm-svn: 170619
for reporting class types from Objective-C runtime
class symbols. Instead, LLDB now queries the
Objective-C runtime for class types.
We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to
prevent regressions when calling class methods in
the V1 runtime.
Other components of this fix include:
- We search the Objective-C runtime in a few more
places.
- We enable enumeration of all members of
Objective-C classes, which Clang does in certain
circumstances.
- SBTarget::FindFirstType and SBTarget::FindTypes
now query the Objective-C runtime as needed.
- I fixed several test cases.
<rdar://problem/12885034>
llvm-svn: 170601
Supporting a compact display syntax for ObjC pointers where 0x00.....0 is replaced by a much more legible "nil"
e.g. this would show:
(NSArray *) $2 = nil
instead of:
(NSArray *) $2 = 0x0000000000000000 <nil>
llvm-svn: 170161
Added a "step-in-target" flag to "thread step-in" so if you have something like:
Process 28464 stopped
* thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1
frame #0: 0x0000000100000e08 a.out`main at main.c:62
61
-> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint.
63
and you want to get into "complex" skipping a, b and c, you can do:
(lldb) step -t complex
Process 28464 stopped
* thread #1: tid = 0x1c03, function: complex , stop reason = step in
frame #0: 0x0000000100000d0d a.out`complex at main.c:44
41
42 int complex (int first, int second, int third)
43 {
-> 44 return first + second + third; // Step in targetting complex should stop here
45 }
46
47 int main (int argc, char const *argv[])
llvm-svn: 170008
the option to print the runtime-specific description has been modified in the frame variable, memory read and expression command.
All three commands now support a --object-description option, with a shortcut of -O (uppercase letter o)
This is a breaking change:
frame variable used --objc as the long option name
expression used -o as a shortcut
memory read uses --objd as the long option name
Hopefully, most users won't be affected by the change since people tend to access "expression --object-description" under the alias "po" which still works
The test suite has been tweaked accordingly.
llvm-svn: 169961
Using this mechanism, making sure that the options to pass a summary string or a named summary to frame variable do not have invalid values
<rdar://problem/11576143>
llvm-svn: 169927
"self" when those pointers are in registers.
Previously in this case the IRInterpreter would
handle them just as if the user had typed in
"$rdi", which isn't safe because $rdi is passed
in through the argument struct.
Now we correctly break out all three cases (i.e.,
normal variables in registers, $reg, and this/self),
and handle them in a way that's a little bit easier
to read and change.
This results in more accurate printing of "this" and
"self" pointers all around. I have strengthened the
optimized-code test case for Objective-C to ensure
that we catch regressions in this area reliably in
the future.
<rdar://problem/12693963>
llvm-svn: 169924
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
- 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
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 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
- 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
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
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
Changed all relevant test cases to verify that MightHaveChildren() works correctly for objects of interest
Added a bunch of convenience methods for test cases to use: target(), process(), thread() and frame() which mimic the lldb.X convenience variables
As a bonus, edited the documentation on the website to describe the new method available for synthetic children providers writers to implement!
That's all folks!
llvm-svn: 166535
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.
llvm-svn: 166472
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
llvm-svn: 166426
LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:
target.arg0 (string) =
There is also the program argument that are separate from the first argument that have existed for a while:
target.run-args (arguments) =
When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args
Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.
llvm-svn: 166137