History log of /external/lldb/include/lldb/lldb-private-interfaces.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
008f3dc79c762b7d240b5ad6d4fb148c5cb039ca 18-Jul-2013 Jim Ingham <jingham@apple.com> This commit does two things. One, it converts the return value of the QueueThreadPlanXXX
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further. If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.

<rdar://problem/14043602>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186618 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
36b877d2d27f7d1890f2d13807a3addb216648e2 25-Apr-2013 Greg Clayton <gclayton@apple.com> Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)).

There is a new static ObjectFile function you can call:

size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)

This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).

This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
7d4083837c5a258375fdc185d464b4ed15759a4b 02-Mar-2013 Jim Ingham <jingham@apple.com> Convert from the C-based LLVM Disassembler shim to the full MC Disassembler API's.
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.

<rdar://problem/11319574>
<rdar://problem/9329275>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176392 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
cbe61bd26db663fa3036866dc33315c6ffc37910 06-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13159777>

lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules.

LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required.

Added a new logging channel for "lldb" called "mmap" to help track future regressions.

Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to.

The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174524 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
188091899842b140313b54e097f16efbe165c998 14-Dec-2012 Greg Clayton <gclayton@apple.com> Cleaned up the UUID mismatch just printing itself whenever it wants to by allowing an optional feedback stream to be passed along when getting the symbol vendor.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170174 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
87e9d32a982a0fb76b8657a897ad5781f9a5d25e 19-Oct-2012 Greg Clayton <gclayton@apple.com> Added the infrastructure necessary for plug-ins to be able to add their own settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at:

plugin
dynamic-loader
macosx-kernel
(bool) disable-kext-loading

To settings can be set using:

(lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true

I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166294 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
f3ec4617297810223deb545cb68214ca4dd8009c 10-Aug-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/11457143 [ER] need "watchpoint command ..."

Add 'watchpoint command add/delete/list' to lldb, plus two .py test files.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161638 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
b1db658333cdebca31a128be95e926d80c3c7796 20-Mar-2012 Greg Clayton <gclayton@apple.com> Platforms can now auto-select themselves if you specify a full target triple when doing a "target create" command.

Each platform now knows if it can handle an architecture and a platform can be found using an architecture. Each platform can look at the arch, vendor and OS and know if it should be used or not.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153104 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
f125250ba7bcaa2ea5ee95539a309e3fd2f8b5d7 29-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10605072>

Added the ability to override command line commands. In some cases GUI interfaces
might want to intercept commands like "quit" or "process launch" (which might cause
the process to re-run). They can now do so by overriding/intercepting commands
by using functions added to SBCommandInterpreter using a callback function. If the
callback function returns true, the command is assumed to be handled. If false
is returned the command should be evaluated normally.

Adopted this up in the Driver.cpp for intercepting the "quit" command.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151708 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
3508c387c3f0c9ecc439d98048fd7694d41bab1b 24-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10103468>

I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151336 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
46c9a355af9b39db78c006b2a5cbf97d3c58d947 09-Feb-2012 Greg Clayton <gclayton@apple.com> First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
b5a8f1498e1ddaeed5187a878d57ea0b74af9c26 05-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10560053>

Fixed "target modules list" (aliased to "image list") to output more information
by default. Modified the "target modules list" to have a few new options:

"--header" or "-h" => show the image header address
"--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)

Removed the "--symfile-basename" or "-S" option, and repurposed it to
"--symfile-unique" "-S" which will show the symbol file if it differs from
the executable file.

ObjectFile's can now be loaded from memory for cases where we don't have the
files cached locally in an SDK or net mounted root. ObjectFileMachO can now
read mach files from memory.

Moved the section data reading code into the ObjectFile so that the object
file can get the section data from Process memory if the file is only in
memory.

lldb_private::Module can now load its object file in a target with a rigid
slide (very common operation for most dynamic linkers) by using:

bool
Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)

lldb::SBModule() now has a new constructor in the public interface:

SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);

This will find an appropriate ObjectFile plug-in to load an image from memory
where the object file header is at "header_addr".




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149804 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
37f962e785be99dc4f0c5e9d02416992ff03bbd0 22-Aug-2011 Greg Clayton <gclayton@apple.com> Added a new plug-in type: lldb_private::OperatingSystem. The operating system
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
75906e4ec98af3717e415727a8d663a4e246bb4f 11-May-2011 Greg Clayton <gclayton@apple.com> Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their
respective ABI plugins as they were plug-ins that supplied ABI specfic info.

Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.

Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131193 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
888a7334344778d1a4edbd58b5852ae4d53ffed9 26-Apr-2011 Greg Clayton <gclayton@apple.com> Changed the emulate instruction function to take emulate options which
are defined as enumerations. Current bits include:

eEmulateInstructionOptionAutoAdvancePC
eEmulateInstructionOptionIgnoreConditions

Modified the EmulateInstruction class to have a few more pure virtuals that
can help clients understand how many instructions the emulator can handle:

virtual bool
SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0;


Where instruction types are defined as:

//------------------------------------------------------------------
/// Instruction types
//------------------------------------------------------------------
typedef enum InstructionType
{
eInstructionTypeAny, // Support for any instructions at all (at least one)
eInstructionTypePrologueEpilogue, // All prologue and epilogue instructons that push and pop register values and modify sp/fp
eInstructionTypePCModifying, // Any instruction that modifies the program counter/instruction pointer
eInstructionTypeAll // All instructions of any kind

} InstructionType;


This allows use to tell what an emulator can do and also allows us to request
these abilities when we are finding the plug-in interface.

Added the ability for an EmulateInstruction class to get the register names
for any registers that are part of the emulation. This helps with being able
to dump and log effectively.

The UnwindAssembly class now stores the architecture it was created with in
case it is needed later in the unwinding process.

Added a function that can tell us DWARF register names for ARM that goes
along with the source/Utility/ARM_DWARF_Registers.h file:

source/Utility/ARM_DWARF_Registers.c

Took some of plug-ins out of the lldb_private namespace.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
8badcb2503ed2e2884a48f66099c1d48494817f4 25-Apr-2011 Greg Clayton <gclayton@apple.com> Renamed UnwindAssemblyProfiler to UnwindAssembly along with its source files.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130156 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
b344843f75ef893762c93fd0a22d2d45712ce74d 24-Mar-2011 Greg Clayton <gclayton@apple.com> Fixed the LLDB build so that we can have private types, private enums and
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128239 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
e4b9c1fb338ee1ada72e6a3c198afb342d68c5c1 08-Mar-2011 Greg Clayton <gclayton@apple.com> LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127286 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
75c703dd8b492bad25a987b96853626641ae7246 16-Feb-2011 Greg Clayton <gclayton@apple.com> The DynamicLoader plug-in instance now lives up in lldb_private::Process where
it should live and the lldb_private::Process takes care of managing the
auto pointer to the dynamic loader instance.

Also, now that the ArchSpec contains the target triple, we are able to
correctly set the Target architecture in DidLaunch/DidAttach in the subclasses,
and then the lldb_private::Process will find the dynamic loader plug-in
by letting the dynamic loader plug-ins inspect the arch/triple in the target.

So now the ProcessGDBRemote plug-in is another step closer to be purely
process/platform agnostic.

I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125650 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
395fc33dc4b06c048ed35047ec461bc092ef2df3 15-Feb-2011 Greg Clayton <gclayton@apple.com> Made lldb_private::ArchSpec contain much more than just an architecture. It
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
b077058fd5c0c0de3261d3da177db360d39edc24 01-Feb-2011 Greg Clayton <gclayton@apple.com> Added EmulateIntruction plug-in manager support.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124644 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
642036f22366d47ea8e6f8498bedb92b88f7f79f 23-Sep-2010 Jim Ingham <jingham@apple.com> Committing the skeleton of Language runtime plugin classes.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114620 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
ea0dbca6e8bc9e6150442e60121f313ea77b5a8f 22-Sep-2010 Jason Molenda <jmolenda@apple.com> Add a new ArchVolatileRegs plugin class to identify
whether a given register number is treated as volatile
or not for a given architecture/platform.

approx 450 lines of boilerplate, 50 lines of actual code. :)



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114537 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
3a4ea24572fad1e22525f8efb718d49d41e30398 10-Sep-2010 Jason Molenda <jmolenda@apple.com> The first part of an lldb native stack unwinder.

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources. One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw. Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs). Only a minimal set of registers is
recovered during a fast stack walk.

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture). When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to
unwind. That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
e49f79dd0afe39829873fa2dcede8ef68b2485f0 12-Jun-2010 Greg Clayton <gclayton@apple.com> Switched over to using the new lldb::SharingPtr from Howard Hinnant.
We need to put this in LLDB since we need to vend this in our API
because our public API uses shared pointers to our private objects.

Removed a deprecated file: include/lldb/Host/Types.h

Added the new SharingPtr.cpp/.h files into source/Utility.

Added a shell script build phase that fixes up all headers in the
LLDB.framework.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105895 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/lldb-private-interfaces.h