History log of /external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
9ea8becea2e54d5a22da3010bb93554af6adbaf0 22-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13455021>

lldb crashes with universal file containing skinny BSD archives when doing DWARF with .o file debugging.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
0e191607adcb0ea8ebd06c278be648a7f5c0097f 10-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13854277>
<rdar://problem/13594769>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:

Changed:

virtual const char * GetPluginName() = 0;

To:

virtual ConstString GetPluginName() = 0;

Removed:

virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.






git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181631 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
97a19b21dacd9063bb5475812df7781777262198 29-Apr-2013 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180717 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
40e278caddf5442776f9408f20d757cc85fe630a 13-Dec-2012 Sean Callanan <scallanan@apple.com> Removed the == and != operators from ArchSpec, since
equality can be strict or loose and we want code to
explicitly choose one or the other.

Also renamed the Compare function to IsEqualTo, to
avoid confusion.

<rdar://problem/12856749>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170152 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
439d6b6eae6bfbfe8eff013444aef9b5cee9db9b 15-Nov-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12125010>

Handle universal BSD archives correctly when parsing DWARF in .o files with debug map.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168075 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
ef9eb809246491a7a9db1f2bd35d854924525ba6 11-Sep-2012 Jason Molenda <jmolenda@apple.com> Remove LLDB_DISABLE_PYTHON ifndef around FormatManager::LoadObjCFormatters() prototype,
it is unconditionally present now.

ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t.

ObjectFile::FindPlugin ditto.

DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163599 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
33a89b28120a021bc26efa562f1774db770146cb 12-Jan-2012 Greg Clayton <gclayton@apple.com> Revert some changes I did for logging that affected the ability to
load .o files in BSD archive parsing.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147987 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
8c5c29611d87850307080783843fb460c27a0729 10-Jan-2012 Greg Clayton <gclayton@apple.com> Make a log timer for the BSD archive creation so we can track the time it
takes to open and index BSD archives.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147813 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Update declarations for all functions/methods that accept printf-style
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
ddb213d2dbc32a505e10a7588583665309238b03 03-Aug-2011 Greg Clayton <gclayton@apple.com> Fixed an issue with parsing object files from .a archives.
The entire .a file gets cached, and after the first .o file
gets loaded, a cached version would get used when trying to
extract the skinny slice from a fat BSD archive and would
cause a code path to get taken in the BSD archive parser
even if we aren't at a BSD archive offset.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136765 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
940b103224f3062578c7a7e6e76d8bf4a7956f2a 23-Feb-2011 Greg Clayton <gclayton@apple.com> Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:

uint32_t
ArchSpec::GetMachOCPUType () const;

uint32_t
ArchSpec::GetMachOCPUSubType () const;

But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@126278 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
67ee10ba771fab5f7288d9c6909c6ffb833234cd 10-Jun-2010 Eli Friedman <eli.friedman@gmail.com> Expand AR_EFMT1 because the define is not present on Linux (and possibly
other systems).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105782 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
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/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp