<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.

llvm-svn: 173463

1 files changed, 2 insertions, 2 deletions

diff --git a/lldb/source/Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.cpp b/lldb/source/Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.cpp
index 2241bc773a5..5641c265675 100644
--- a/lldb/source/Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.cpp
+++ b/lldb/source/Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.cpp
@@ -75,7 +75,7 @@ ObjectContainerUniversalMachO::CreateInstance
 bool
 ObjectContainerUniversalMachO::MagicBytesMatch (const DataExtractor &data)
 {
-    uint32_t offset = 0;
+    lldb::offset_t offset = 0;
     uint32_t magic = data.GetU32(&offset);
     return magic == UniversalMagic || magic == UniversalMagicSwapped;
 }
@@ -105,7 +105,7 @@ ObjectContainerUniversalMachO::ParseHeader ()
 {
     // Store the file offset for this universal file as we could have a universal .o file
     // in a BSD archive, or be contained in another kind of object.
-    uint32_t offset = 0;
+    lldb::offset_t offset = 0;
     // Universal mach-o files always have their headers in big endian.
     m_data.SetByteOrder (eByteOrderBig);
     m_header.magic = m_data.GetU32(&offset);