<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
This commit is contained in:
@@ -73,8 +73,8 @@ BreakpointResolverFileLine::SearchCallback
|
||||
// So we go through the match list and pull out the sets that have the same file spec in their line_entry
|
||||
// and treat each set separately.
|
||||
|
||||
uint32_t num_comp_units = context.module_sp->GetNumCompileUnits();
|
||||
for (uint32_t i = 0; i < num_comp_units; i++)
|
||||
const size_t num_comp_units = context.module_sp->GetNumCompileUnits();
|
||||
for (size_t i = 0; i < num_comp_units; i++)
|
||||
{
|
||||
CompUnitSP cu_sp (context.module_sp->GetCompileUnitAtIndex (i));
|
||||
if (cu_sp)
|
||||
|
||||
Reference in New Issue
Block a user