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
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
This reverts commit 4a5ad2c077166cc3d6e7ab4cc6e3dcbbe922af86.
Windows doesn't support select() for pipe objects, and this also fails
to compile on Windows. Reverting this until we can get it sorted out
to keep the windows build working.
llvm-svn: 223392
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDIE (
DWARFCompileUnit* dwarf_cu,
const DWARFDebugInfoEntry *die,
const lldb_private::ConstString &type_name);
This function isn't used as it has been replaced by:
lldb::TypeSP
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (
const DWARFDeclContext &die_decl_ctx);
I am about to change the way we resolve C/C++ class/struct/union types and want to clean up SymbolFileDWARF before I start.
llvm-svn: 223376
This is a temporary workaround to get deferred breakpoint
resolution working until Bug 21720 is addressed. Even with this
workaround, it will only resolve deferred breakpoints in the
executable module, and not in a shared library.
llvm-svn: 223273
Previously if we got a DoDestroy while stopped at a breakpoint, we
would detach and then say the process had exited. This is completely
wrong, as it resulted in the python script incorrectly assuming that
the process had actually exited and trying to delete the image, when
in fact it had done no such thing.
The fix employed here is that when we get a DoDestroy, we do 3 steps:
1) initiate a termination sequence on the process
2) If we were stopped handling an exception of any kind, mask it and
let the program resume, causing the program to see the termination
request and exit on its own.
3) Let the program exit normally, and close all of our handles before
returning control back to DoDestroy.
This fixes Bug 21722 and Bug 21723.
llvm-svn: 223272
preserved) in the ABI.
Realistically lldb isn't able to track register saves of any of
the neon regs right now so we should probably mark all of the
regs as unavailable when you're not on stack frame 0...
<rdar://problem/19115127>
llvm-svn: 223174
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
This was fixed by making the DWARFFormValue contain the compile unit that it needs so it can decode its form value correctly. Any form value that requires a compile unit will now assert. If any of the assertions that were added are triggered, then code that led to the extraction of the form value without properly setting the compile unit must be fixed immediately.
<rdar://problem/19035440>
llvm-svn: 222602
UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on
that same stack frame before it tries the fallback unwind plan
on the "next" or callee frame.
In RegisterContextLLDB::TryFallbackUnwindPlan, when we're
trying the fallback unwind plan to see if it is valid, make
sure we change all of the object ivars that might be used in
the process of fetching the CFA & caller's saved pc value
and restore those if we decide not to use the fallback
unwindplan.
<rdar://problem/19035079>
llvm-svn: 222601
LLDB supports many different register numbering schemes, and these
are typically prefixed with an indicator that lets the user know
what numbering scheme is used. The gcc numbering scheme is
prefixed with gcc, and there are similar ones for dwarf, gdb,
and gcc_dwarf.
LLDB also contains its own internal numbering scheme, but the enum
for LLDB's numbering scheme was prefixed differently. This patch
changes the names of these enums to use the same naming scheme for
the enum values as the rest of the register kinds by removing gpr_
and fpu_ prefixes, and instead using lldb_ prefixes for all enum
values.
Differential Revision: http://reviews.llvm.org/D6351
Reviewed by: Greg Clayton
llvm-svn: 222495
Running a diff against lldb-x86-register-enums.h and the file
modified in this patch, the two enums were completely identical.
Deleting one of them to reduce code noise.
llvm-svn: 222478
This implements the skeleton of a RegisterContext for Windows.
In particular, this implements support only for x86 general purpose
registers.
After this patch, LLDB on Windows can perform basic debugging
operations in a single-threaded inferior process (breakpoint,
register inspection, frame select, unwinding, etc).
Differential Revision: http://reviews.llvm.org/D6322
Reviewed by: Greg Clayton
llvm-svn: 222474
where it is retrieving the Return Address register contents
on a target where that's a thing. If we fail to get a valid
RA, we force a switch to the fallback unwind plan. This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211>
llvm-svn: 222301
Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type. This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185
Previously we were directly updating the thread list and stopping
and restarting the process every time threads were created. With
this patch, we queue up thread launches and thread exits, resolve
these all internally, and only update the threads when we get an
UpdateThreadList call. We now only update the private state on
an actual stop (i.e. breakpoint).
llvm-svn: 222178
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
This creates a TargetThreadWindows class and updates the thread
list of the Process with the main thread. Additionally, we
fill out a few more overrides of Process base class methods. We
do not yet update the thread list as threads are created and/or
destroyed, and we do not yet propagate stop reasons to threads as
their states change.
llvm-svn: 222148
RegisterContextLLDB. I have core files of half a dozen tricky
unwind situations on x86/arm and they're all working pretty much
correctly at this point, but we'll need to keep an eye out for
unwinder regressions for a little while; it's tricky to get these
heuristics completely correct in all unwind situations.
<rdar://problem/18937193>
llvm-svn: 221866
This sends notifications for module load / unload to the process
plugin, and also manages the state more accurately during the
loading sequence.
Similar work by Virgile Bello was referenced during the
implementation of this patch.
Differential Revision: http://reviews.llvm.org/D6224
llvm-svn: 221807
Due to a previous multi-threaded design involving message
passing, we used message classes to pass event information
to the delegate. Since the multi-threaded design has gone
away, we simplify this by passing event arguments as direct
function parameters, which is more clear and easier to
understand.
llvm-svn: 221806
After r221575 TestCallStopAndContinue and TestCallThatRestarts started
crashing on FreeBSD with a null temporary_module_sp in
RegisterContextLLDB::InitializeNonZerothFrame().
llvm-svn: 221805
The addition of RegisterNumber introduced a bug where if the PC is stored in a
return address register, such as on ARM and PowerPC, this register number is
retrieved and used, but never checked in the row if it's saved. Correct this by
setting the variable that's used to the new register number.
Patch by Jason Molenda.
llvm-svn: 221790
Summary:
Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add
full stack unwind support to the PowerPC/PowerPC64 ABI. Also, add a new
register set for powerpc32-on-64, so the register sizes are correct. This also
requires modifying the ProcessMonitor to add support for non-uintptr_t-sized
register values.
Reviewers: jasonmolenda, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6183
llvm-svn: 221789
Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788
ObjectFileMachO. It's close but we seem to be missing some
of the memory region segments - not exactly sure how that's
happening. The register context writing into the LC_THREAD
load commands is working correctly though.
Slightly reordered the arm64 definitions in ArchSpec.cpp so
when we look for an arm64 core file definiton we're getting
a cpu subtype of CPU_ANY which we can't put in the mach
header of a core file. Make the first definition we find by
linear search have the currently correct '1' cpu subtype.
llvm-svn: 221743
Jim Ingham