| 7980d35608225dc71b3dd946d4c3aea85bc24e85 |
|
13-Jul-2013 |
Greg Clayton <gclayton@apple.com> |
Fixed GetModuleSpecifications() to work better overall:
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186211 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 7940069905bee0b2e5f0661bf37c9f906ddf8603 |
|
10-Jul-2013 |
Greg Clayton <gclayton@apple.com> |
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)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185990 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| a807ceef5dad2b24e5bae5c5a193ff03aa7ec8d9 |
|
01-Jul-2013 |
Michael Sartain <mikesart@valvesoftware.com> |
Split symbol support for ELF and Linux.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 81a96aa6242f7b559770f5dc62316253cb8cb0d4 |
|
18-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.
Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 464a5063bc59755cb6ec063d0b2491097302d2ab |
|
04-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13338643>
DWARF with .o files now uses 40-60% less memory!
Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
- Lazily parse the debug map for each object file
- not require the address map for a .o file until debug information is linked for a .o file
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176454 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 3cf7ab5462467121b4ac6cde09ee994030dad0c5 |
|
06-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11109570>
The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 36da2aa6dc5ad9994b638ed09eb81c44cc05540b |
|
25-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13069948>
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 49ce8969d3154e1560106cfe530444c09410f217 |
|
29-Aug-2012 |
Greg Clayton <gclayton@apple.com> |
<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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 7fb143064009e34dbb7a602924e9807375f72a46 |
|
13-Apr-2012 |
Greg Clayton <gclayton@apple.com> |
Expose GetAddressClass() from both the SBAddress and SBInstruction so clients can tell the difference between ARM/Thumb opcodes when disassembling ARM.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154633 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 598df88bd6fc33c6fb330bc859bdc277795501f3 |
|
14-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10434005>
Prepare LLDB to be built with C++11 by hiding all accesses to std::tr1 behind
macros that allows us to easily compile for either C++.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 9482f05e109d617061c1ade6d9672dfcb8427547 |
|
14-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11034170>
Simplify the locking strategy for Module and its owned objects to always use the Module's mutex to avoid A/B deadlocks. We had a case where a symbol vendor was locking itself and then calling a function that would try to get it's Module's mutex and at the same time another thread had the Module mutex that was trying to get the SymbolVendor mutex. Now any classes that inherit from ModuleChild should use the module lock using code like:
void
ModuleChildSubclass::Function
{
ModuleSP module_sp(GetModule());
if (module_sp)
{
lldb_private::Mutex::Locker locker(module_sp->GetMutex());
... do work here...
}
}
This will help avoid deadlocks by using as few locks as possible for a module and all its child objects and also enforce detecting if a module has gone away (the ModuleSP will be returned empty if the weak_ptr does refer to a valid object anymore).
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 49f4bf21e0fb7675d67f95dafe66a098d3205650 |
|
22-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151190 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 9ce953807eb814a93b449dc243de4f7bf32c3115 |
|
14-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| ac725afac61b48d1dc0e38370d824fe45c52c3b7 |
|
10-Feb-2012 |
Sean Callanan <scallanan@apple.com> |
Improved detection of object file types, moving
detection of kernels into the object file and
adding a new category for raw binary images.
Fixed all clients who previously searched for
sections manually, making them use the object
file's facilities instead.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150272 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 13d24fb1817faa7ccc4cfd799113ba1a2b8968eb |
|
29-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| db2dc2b824b61ef7578dc8cdad7b338aa82b1f17 |
|
12-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
Big change in the way ObjectFile file contents are managed. We now
mmap() the entire object file contents into memory with MAP_PRIVATE.
We do this because object file contents can change on us and currently
this helps alleviate this situation. It also make the code for accessing
object file data much easier to manage and we don't end up opening the
file, reading some data and closing the file over and over.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148017 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| e40b6424d9e49306392bec4b44060da36414c382 |
|
18-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
Don't put modules for .o files into the global shared module list. We
used to do this because we needed to find the shared pointer for a .o
file when the .o file's module was needed in a SymbolContext since the
module in a symbol context was a shared pointer. Now that we are using
intrusive pointers we don't have this limitation anymore since any
instrusive shared pointer can be made from a pointer to an object
all on its own.
Also switched over to having the Module and SymbolVendor use shared
pointers to their object files as had a leak on MacOSX when the
SymbolVendor's object file wasn't the same as the Module's (debug info
in a stand along file (dSYM file)). Now everything will correctly clean
itself up when the module goes away after an executable gets rebuilt.
Now we correctly get rid of .o files that are used with the DWARF with
debug map executables on subsequent runs since the only shared pointer
to the object files in from the DWARF symbol file debug map parser, and
when the module gets replaced, it destroys to old one along with all .o
files.
Also added a small optimization when using BSD archives where we will
remove old BSD containers from the shared list when they are outdated.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140002 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 2bc9eb3ba78efc64a273729b480bafc3bbaa433a |
|
19-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Patch by Matt Johnson to silence G++ warnings!
Used hand merge to apply the diffs. I did not apply the diffs for FormatManager.h and
the diffs for memberwise initialization for ValueObject.cpp because they changed since.
I will ask my colleague to apply them later.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135508 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| ca31997f0ff24dbba39623054d5a94a0181c52d6 |
|
09-Jul-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to get an abstract file type (executable, object file,
shared library, etc) and strata (user/kernel) from an object file. This will
help with plug-in and platform selection when given a new binary with the
"target create <file>" command.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| b1888f24fa181489840b9acf193e224d125d0776 |
|
19-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Added more platform support. There are now some new commands:
platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)
When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can
do:
(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib
Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.
This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127934 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| e45140f9916841ea356ef707541945efa20ba042 |
|
08-Mar-2011 |
Jim Ingham <jingham@apple.com> |
I didn't notice there was already an ObjectFile::GetEntryPoint. Move that over to GetEntryPointAddress 'cause that's more consistent with other functions in ObjectFile, do the mutatis mutandi and also in the ELF case I return a section offset address rather than a bare load address.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127205 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 2877594f4442cfc4d0ed2abd30af6b8027a84fc1 |
|
08-Mar-2011 |
Jim Ingham <jingham@apple.com> |
Add a method "GetEntryPoint" to the ObjectFile class, and implement it on MachO & ELF - though the ELF implementation is probably a little weak. Then use this method in place of directly looking for "start" in the ThreadPlanCallFunction constructor to find the stopping point for our function evaluation.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127194 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 5f54ac373b119a4c6693e4875c48aa761fba0c86 |
|
08-Feb-2011 |
Greg Clayton <gclayton@apple.com> |
Moved FileSpec into the Host layer since it will vary from host to host.
We have a common unix implementation in lldb/source/Host/common/FileSpec.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125078 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 0467c78e9a75eff9ec33d3c1f39fa83e1c5d9241 |
|
04-Feb-2011 |
Greg Clayton <gclayton@apple.com> |
Applied a fix to qualify "UUID" with the lldb_private namespace to fix
build issues on MinGW.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124888 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| cd548034fa23113e995b8463d14f910ba2f7298c |
|
01-Feb-2011 |
Greg Clayton <gclayton@apple.com> |
Endian patch from Kirk Beitz that allows better cross platform building.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 7ec8105eba4b76ac8ba5f61a11c2a9a2548369ca |
|
14-Jan-2011 |
Stephen Wilson <wilsons@start.ca> |
Extend the ObjectFile interface to support dynamic loading on ELF platforms.
Debuggers on ELF platforms hook into the runtime linker by monitoring a special
"rendezvous" embedded in the address space of the inferior process. The exact
location of this structure is filled in by the runtime linker and can be
resolved by locating the DT_DEBUG entry in the processes .dynamic section. The
new GetImageInfoAddress() method (morally equivalent to
Process::GetImageInfoAddress) provides the mechanism to locate this information.
GetEntryPoint() simply returns the address of the start symbol in the executable
if present. It is useful to the dynamic loader plugin for ELF systems as this
is the earliest point where LLDB can break and probe the inferiors .dynamic
section and rendezvous structure. Also, this address can be used in the
computation of the virtual base address for position independent executables.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| fe424a92fc6fd92f810d243912461fe028a2b63c |
|
18-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
General command line help cleanup:
- All single character options will now be printed together
- Changed all options that contains underscores to contain '-' instead
- Made the help come out a little flatter by showing the long and short
option on the same line.
- Modified the short character for "--ignore-count" options to "-i"
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114265 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|
| 7508e732818c32e1cfeaaf7d1d507fe3834ce9d2 |
|
10-Aug-2010 |
Jim Ingham <jingham@apple.com> |
Change Target & Process so they can really be initialized with an invalid architecture.
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".
Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@110624 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| 2d84974fcfcf8ee02fce6a8d73d21be7b5d1a880 |
|
20-Jul-2010 |
Stephen Wilson <wilsons@start.ca> |
Add missing include.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108878 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.h
|
| cf0150574a0a97049efe2dce2cc0aa433705feb3 |
|
11-Jun-2010 |
Greg Clayton <gclayton@apple.com> |
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu
type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file.
Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.
Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105806 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Symbol/ObjectFile.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/Symbol/ObjectFile.h
|