Commit Graph

54 Commits

Author SHA1 Message Date
Greg Clayton fbb7634934 Expose SBPlatform through the public API.
Example code:

remote_platform = lldb.SBPlatform("remote-macosx"); 
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)

connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); 
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
    print >> result, 'Connected to remote platform:'
    print >> result, 'hostname: %s' % (remote_platform.GetHostname())
    src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
    dst = lldb.SBFileSpec()
    # copy src to platform working directory since "dst" is empty
    err = remote_platform.Install(src, dst);
    if err.Success():
        print >> result, '%s installed successfully' % (src)
    else:
        print >> result, 'error: failed to install "%s": %s' % (src, err)


Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.

The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.

The API in SBPlatform is subject to change and will be getting many new functions.

llvm-svn: 195273
2013-11-20 21:07:01 +00:00
Greg Clayton 57ee306789 Huge change to clean up types.
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.

llvm-svn: 186130
2013-07-11 22:46:58 +00:00
Greg Clayton 3046e66830 Cleanup on the unified section list changes. Main changes are:
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.

Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)

llvm-svn: 185990
2013-07-10 01:23:25 +00:00
Greg Clayton 226cce2511 Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:

lldb::SBModuleSpec
lldb::SBModuleSpecList

The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.

llvm-svn: 185877
2013-07-08 22:22:41 +00:00
Michael Sartain a7499c9830 Split symbol support for ELF and Linux.
llvm-svn: 185366
2013-07-01 19:45:50 +00:00
Greg Clayton f02500c74c Added the ability to get a list of types from a SBModule or SBCompileUnit. Sebastien Metrot wanted this, and sent a hollowed out patch. I filled in the blanks and did the low level implementation. The new functions are:
//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// module.
///
/// @param[in] type_mask
///     A bitfield that consists of one or more bits logically OR'ed
///     together from the lldb::TypeClass enumeration. This allows
///     you to request only structure types, or only class, struct
///     and union types. Passing in lldb::eTypeClassAny will return
///     all types found in the debug information for this module.
///
/// @return
///     A list of types in this module that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBModule::GetTypes (uint32_t type_mask)


//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// compile unit.
///
/// @param[in] type_mask
///    A bitfield that consists of one or more bits logically OR'ed
///    together from the lldb::TypeClass enumeration. This allows
///    you to request only structure types, or only class, struct
///    and union types. Passing in lldb::eTypeClassAny will return
///    all types found in the debug information for this compile
///    unit.
///
/// @return
///    A list of types in this compile unit that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBCompileUnit::GetTypes (uint32_t type_mask = lldb::eTypeClassAny);

This lets you request types by filling out a mask that contains one or more bits from the lldb::TypeClass enumerations, so you can only get the types you really want.

llvm-svn: 184251
2013-06-18 22:51:05 +00:00
Jason Molenda c16b4af0d7 Remove the UUID::GetAsCString() method which required a buffer to save the
UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string.  Updated callers to use the new method.

llvm-svn: 181078
2013-05-03 23:56:12 +00:00
Greg Clayton b5ad4ec7a3 Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules:
std::string
Module::GetSpecificationDescription () const;

This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.

llvm-svn: 180717
2013-04-29 17:25:54 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191
2013-03-27 23:08:40 +00:00
Enrico Granata 85425d77b8 <rdar://problem/13107151>
SBValueList was backed by a ValueObjectList. This caused us to lose track of the additional metadata in the ValueImpl that backs SBValue.
This checkin fixes that by backing SBValueList with ValueListImpl (that essentially wraps a vector<SBValue>).

llvm-svn: 174638
2013-02-07 18:23:56 +00:00
Greg Clayton 39f7ee86c8 <rdar://problem/13092722>
Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD.

Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match.

Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid.

llvm-svn: 174222
2013-02-01 21:38:35 +00:00
Enrico Granata bcd80b4723 <rdar://problem/13021266>
Adding FindFirstGlobalVariable to SBModule and SBTarget
These calls work like FindGlobalVariables but they only return the first match found and so they can return an SBValue instead of an SBValueList for added convenience of use

llvm-svn: 172636
2013-01-16 18:53:52 +00:00
Greg Clayton b43165b7a5 <rdar://problem/12749733>
Always allows getting builtin types by name even if there is no backing debug information.

llvm-svn: 169424
2012-12-05 21:24:42 +00:00
Greg Clayton e14e19253d <rdar://problem/12750060>
Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects.

llvm-svn: 169205
2012-12-04 02:22:16 +00:00
Enrico Granata 3467d80ba3 <rdar://problem/11485744> Implement important data formatters in C++. Have the Objective-C language runtime plugin expose class descriptors objects akin to the objc_runtime.py Pythonic implementation. Rewrite the data formatters for some core Cocoa classes in C++ instead of Python.
llvm-svn: 163155
2012-09-04 18:47:54 +00:00
Greg Clayton 1f7460716b <rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860
2012-08-29 21:13:06 +00:00
Greg Clayton 84db9105d2 <rdar://problem/11113279>
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482
2012-03-26 23:03:23 +00:00
Johnny Chen 873a7a4b64 Patch from dawn@burble.org:
GetSupportFileAtIndex(), GetNumSupportFiles(), FindSupportFileIndex():
   Add API support for getting the list of files in a compilation unit.
GetNumCompileUnits(), GetCompileUnitAtIndex():
   Add API support for retrieving the compilation units in a module.

llvm-svn: 152942
2012-03-16 20:46:10 +00:00
Greg Clayton e72dfb321c <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.

llvm-svn: 151336
2012-02-24 01:59:29 +00:00
Greg Clayton c2ff9318a2 Added the ability to get a ObjectFile versions from the ObjectFile
subclasses if the object files support version numbering. Exposed
this through SBModule for upcoming data formatter version checking stuff.

llvm-svn: 151190
2012-02-22 19:41:02 +00:00
Greg Clayton c859e2d524 Full core file support has been added for mach-o core files.
Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries. 

llvm-svn: 150426
2012-02-13 23:10:39 +00:00
Sean Callanan 9df05fbb7f Extended function lookup to allow the user to
indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.

llvm-svn: 150279
2012-02-10 22:52:19 +00:00
Greg Clayton 5569e64ea7 Removed all of the "#ifndef SWIG" from the SB header files since we are using
interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853
2012-02-06 01:44:54 +00:00
Greg Clayton c96605461c <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".

llvm-svn: 149804
2012-02-05 02:38:54 +00:00
Greg Clayton acdbe81637 lldb::SBTarget and lldb::SBProcess are now thread hardened. They both still
contain shared pointers to the lldb_private::Target and lldb_private::Process
objects respectively as we won't want the target or process just going away.

Also cleaned up the lldb::SBModule to remove dangerous pointer accessors.

For any code the public API files, we should always be grabbing shared 
pointers to any objects for the current class, and any other classes prior
to running code with them.

llvm-svn: 149238
2012-01-30 09:04:36 +00:00