| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 194413
|
|
|
|
| |
llvm-svn: 194397
|
|
|
|
|
|
|
| |
These were previously missing in g_register_infos_x86_64 and so arg
lookup failed on FreeBSD and Linux after r194035.
llvm-svn: 194392
|
|
|
|
|
|
|
|
| |
something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068>
llvm-svn: 194367
|
|
|
|
|
|
|
|
| |
something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068>
llvm-svn: 194366
|
|
|
|
| |
llvm-svn: 194363
|
|
|
|
|
|
| |
There were 6 on darwin. All of these were related to the recent changes for exec.
llvm-svn: 194298
|
|
|
|
| |
llvm-svn: 194295
|
|
|
|
|
|
|
|
| |
Still working out some of the details of these classes but
I wanted to get the overall structure checked in.
<rdar://problem/15314068>
llvm-svn: 194245
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.
Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.
llvm-svn: 194232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
|
|
|
|
| |
llvm-svn: 194163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iterators for LLDB's container data structures.
Iterable abstracts over the backing data structure,
ignoring keys for maps for example. It also provides
locking as a service so that the code
for (ThreadSP thread_sp : process->Threads())
{
// ... use thread_sp
}
takes the appropriate locks once, without having to
do anything else.
The salient advantages of this system are:
- Much simpler and idiomatic loop code
- Lock once instead of each time an element is fetched
- Less boilerplate to produce the iterators
The intent is that Iterable will replace Get...AtIndex
in most places, and that ForEach(), which solves the
same problem in a less-idiomatic way, be phased out in
favor of this approach.
I've added Iterables to ThreadList, TypeList, and
Process (which is really just forwarding to ThreadList).
llvm-svn: 194159
|
|
|
|
|
|
|
| |
bit from the method names.
<rdar://problem/15314369>
llvm-svn: 194122
|
|
|
|
|
|
| |
return bogus values for GetLoadAddress() and GetFileAddress().
llvm-svn: 194120
|
|
|
|
|
|
|
| |
SystemRuntime and SBThread classes.
<rdar://problem/15314369>
llvm-svn: 194111
|
|
|
|
|
|
|
|
| |
Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin.
The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information.
llvm-svn: 194106
|
|
|
|
|
|
|
|
| |
be parsed.
<rdar://problem/15390829>
llvm-svn: 194087
|
|
|
|
|
|
|
|
|
|
|
| |
GetThreadOriginExtendedBacktraceTypeAtIndex methods to
SBProcess.
Add documentation for the GetQueueName and GetQueueID methods
to SBThread.
<rdar://problem/15314369>
llvm-svn: 194063
|
|
|
|
|
|
|
| |
SystemRuntime class.
<rdar://problem/15314369>
llvm-svn: 194045
|
|
|
|
|
|
|
| |
class, not any actual plugin implementation yet.
<rdar://problem/15314068>
llvm-svn: 194044
|
|
|
|
|
|
|
|
| |
Instead of looking up registers by name, we use the generic ID when we can.
Also added code that creates an extra frame when running expressions by pushing the current PC and FP and then hooking up the FP backchain. This code is "#if 0" out for now until we can pair it with unwinder fixes.
llvm-svn: 194035
|
|
|
|
|
|
| |
the stack pointer.
llvm-svn: 194029
|
|
|
|
|
|
|
| |
where it was using the wrong register numbering scheme
to express where the rbp could be retrieved from.
llvm-svn: 194023
|
|
|
|
|
|
|
|
| |
Fixed a case where on darwin, after recent compiler changes a few months ago, we could not execute dlopen() in an expression, or use "process load".
The issue was some compiler option default values changed. We now override these settings to get the old behavior back.
llvm-svn: 194012
|
|
|
|
|
|
|
|
| |
Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments.
The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen.
llvm-svn: 194009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at some point in the past. We may have nothing more than a pc value
for this type of stack frame -- hopefully we'll have a pc and a
stop_id so we can track module loads and unloads over time and
symbolicate the pc at the correct point in time.
Also add a flag to indicate if the CFA for the frame is available
(a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an
overall setting to indicate whether this is a history stack frame
or not. A history stack frame may not have a CFA, it may not have
a register context, it may not have variables, it may not have a
frame pointer or a stack pointer.
<rdar://problem/15314068>
llvm-svn: 193987
|
|
|
|
|
|
|
|
|
|
| |
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
|
|
|
| |
llvm-svn: 193972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
|
|
|
|
|
|
|
|
|
|
| |
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.
Fixes bug #17551.
Patch by "/dev/humancontroller"
llvm-svn: 193832
|
|
|
|
|
|
| |
ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command
llvm-svn: 193818
|
|
|
|
|
|
| |
auto-one-line-summaries
llvm-svn: 193801
|
|
|
|
| |
llvm-svn: 193794
|
|
|
|
| |
llvm-svn: 193792
|
|
|
|
|
|
| |
Scalar manipulation logic found in ValueObject, but rather just call down to it
llvm-svn: 193786
|
|
|
|
|
|
| |
built in demangler. This will help us track when we need to update this file.
llvm-svn: 193784
|
|
|
|
|
|
|
|
| |
FreeBSD includes the elftoolchain project's demangler in the base system.
It does not handle some unusual mangled names, so use the inlined
libcxxabi one.
llvm-svn: 193776
|
|
|
|
|
|
| |
Fixes from code review by Jim Ingham that reinstate preferring an external vs non-external symbol when finding function addresses.
llvm-svn: 193761
|
|
|
|
|
|
|
|
|
|
|
|
| |
bind to a ValueObject internally depending on any criteria
User-vended by-type formatters still would prevail on these hardcoded ones
For the time being, while the infrastructure is there, no such formatters exist
This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it
llvm-svn: 193724
|
|
|
|
|
|
| |
Fixed the expression parser to be able to iterate across all function name matches that it finds when it is looking for the address of a function that the IR is looking for. Also taught it to deal with reexported symbols.
llvm-svn: 193716
|
|
|
|
|
|
|
|
|
|
| |
Inlined a copy of cxa_demangle.cpp from:
http://llvm.org/svn/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp
For systems that don't have demangling built into the system, and for systems that don't want to use the version that is installed. Defining LLDB_USE_BUILTIN_DEMANGLER in your build system allows you to use the built in demangler. This setting is curently automatically enabled for Windows builds.
llvm-svn: 193708
|
|
|
|
|
|
| |
recently added virtual function. Renamed GetSDKDirectory to GetSDKsDirectory to fix the issue. GetSDKsDirectory is a better fit because it finds the directory that contains all SDKs, not the current one.
llvm-svn: 193707
|
|
|
|
|
|
|
|
|
| |
Fixing a problem where ValueObject::GetPointeeData() would not accept "partial" valid reads (i.e. asking for 10 items and getting only 5 back)
While suboptimal, this situation is not a flat-out failure and could well be caused by legit scenarios, such as hitting a page boundary
Among others, this allows data formatters to print char* buffers allocated under libgmalloc
llvm-svn: 193704
|
|
|
|
|
|
|
| |
CFNumberRef is toll-free bridged to NSNumber
We can use the same summary formatter for both types
llvm-svn: 193666
|
|
|
|
|
|
|
| |
One of the things that dynamic typing affects is the count of children a type has
Clear out the flag that makes us blindly believe the children count when a dynamic type change is detected
llvm-svn: 193663
|
|
|
|
|
|
|
|
|
|
| |
Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g.
x -f c -s 10 buffer
This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1
In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading.
llvm-svn: 193659
|
|
|
|
|
|
|
|
| |
a valid SBType given debug information
Added a test case to help us detect regression in this realm
llvm-svn: 193631
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reimplements the TypeImpl class (the class that backs SBType) in terms of a static,dynamic type pair
This is useful for those cases when the dynamic type of an ObjC variable can only be obtained in terms of an "hollow" type with no ivars
In that case, we could either go with the static type (+iVar information) or with the dynamic type (+inheritance chain)
With the new TypeImpl implementation, we try to combine these two sources of information in order to extract as much information as possible
This should improve the functionality of tools that are using the SBType API to do extensive dynamic type inspection
llvm-svn: 193564
|
|
|
|
|
|
| |
<rdar://problem/15208799>
llvm-svn: 193530
|