Objective-C types and enums in modules. We now have
a three-stage fallback when looking for methods and
properties: first the DWARF, second the modules, third
the runtime.
<rdar://problem/18782288>
llvm-svn: 223939
Fix PR21802 by correcting the destruction order of
`ClangExpressionParser` and `IRExecutionUnit` in `ClangFunction`. The
former has hooks into the latter -- i.e., `clang::CGDebugInfo` points at
the `LLVMContext` -- so it needs to be torn down first.
This was exposed by r223802 in LLVM, which started doing work in the
`CGDebugInfo` teardown.
llvm-svn: 223916
Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem
This patch transitions that code into a hardcoded summary
llvm-svn: 223906
clang does not yet support MS-ABI record layout for externally-sourced
ASTs. As a result, attempting to format something that requires data
layout results in undefined behavior in clang, in this case an assert.
http://llvm.org/pr21800 tracks fixing this on the clang side.
llvm-svn: 223868
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
a register value that is live in the stack frame 0 register context.
Fixes a problem where retrieving a register value on stack frame #n
would involved O(n!) stack frame checks. This could be very slow on
a deep stack when retrieving register values that had not been
modified/saved by any of the stack frames. Not common, but annoying
when it was hit.
<rdar://problem/19010211>
llvm-svn: 223843
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
track of the checksum of the object so we can
track if it is modified. This fixes a testcase
(test/expression_command/issue_11588) on OS X.
Patch by Enrico Granata.
llvm-svn: 223830
- adds a new flag to mark ValueObjects as "synthetic children generated"
- vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically
- moves synthetic child providers over to using these new functions
No visible feature change, but preparatory work for feature change
llvm-svn: 223819
Getting this working correctly is a significant amount of work.
Assertions on Windows show up as error code 0xC0000409, which is
STATUS_STACK_BUFFER_OVERRUN. In order to accurately determine
that this is not just any stack buffer overrun, but one triggered
by a call to abort, we would need to analyze the call stack. This
in turn requires better symbol support for Windows executables,
and work on LLDB to make stack frames better on Windows.
For now, these are XFAIL'ed and tracked in http://llvm.org/pr21793.
llvm-svn: 223816
Summary:
Test Plan: Connect to a remote implementing the platform protocol (ds2 in this case), run `platform process list` and see processes being displayed.
Reviewers: vharron, tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6571
llvm-svn: 223752
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
This is a resubmit of r223548, which was reverted due to breaking
tests on Linux and Mac.
This resubmit fixes the reason for the revert by adding back some
accidentally removed code which appends -c to the command line
when running /bin/sh.
This resubmit also differs from the original patch in that it sets
the architecture on the ProcessLaunchInfo. A follow-up patch will
refactor this to separate the logic for different platforms.
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223695
There was an error in ORing mask which is used for getting a list of variables.
Previously, these constants were unnamed, and possible it become the reason of this
bug. Also added test case for -stack-list-local and -stack-list_arguments.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 223674
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
encounter clang::ExternalASTSources that are not instances
of ClangExternalASTSourceCommon. We used to blithely
assume that all are, and so we could use static_cast<>.
That's no longer the case, so we have to have these AST
sources register themselves.
llvm-svn: 223560
type format info
type summary info
type synthetic info
These commands all take an expression, evaluate it, and show which of the respective formatter (if any) applies to the result of the expression
Fixes rdar://12059317
llvm-svn: 223511
Summary: If lldb is not built, dotest.py throws an exception because we are using an unset variable.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6516
llvm-svn: 223446
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
Sean Callanan