summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2013-08-16 03:20:42 +0000
committerJason Molenda <jmolenda@apple.com>2013-08-16 03:20:42 +0000
commit20eb31b9073ebb19cc24f225e1b6bed69de8931c (patch)
tree16d3db997b918dd26f5cd4d424ec8a4156d6521e /lldb/source/Plugins/ObjectFile
parent2393799609dc72a65fde6d2224bb6db83e138e01 (diff)
downloadbcm5719-llvm-20eb31b9073ebb19cc24f225e1b6bed69de8931c.tar.gz
bcm5719-llvm-20eb31b9073ebb19cc24f225e1b6bed69de8931c.zip
Add a new Section::SetFileAddress method to change a Section's file
address. When loading a dSYM, and the file addresses of the dSYM Sections are different than the executable binary Sections' file addresses, the debug info won't be remapped to the actual load addresses correctly. This only happens with binaries on the in-memory shared cache binaries where their File addresses have been set to their actual load address (outside an offset value) whereas the original executable and dSYM have 0-based File addresses. I think this patch will not be activated for other cases -- this is the only case we know of where the dSYM and the executable's File addresses differ -- but if this causes other problems we can restrict it more carefully. <rdar://problem/12335086> llvm-svn: 188532
Diffstat (limited to 'lldb/source/Plugins/ObjectFile')
-rw-r--r--lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp34
1 files changed, 24 insertions, 10 deletions
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index e8d31181bd6..5b4695ede05 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1035,11 +1035,11 @@ ObjectFileMachO::CreateSections (SectionList &unified_section_list)
// is null out the SectionList vector and if a process has been set up, dump a message
// to stdout. The most common case here is core file debugging with a truncated file.
const char *lc_segment_name = load_cmd.cmd == LoadCommandSegment64 ? "LC_SEGMENT_64" : "LC_SEGMENT";
- GetModule()->ReportError("is a corrupt mach-o file: load command %u %s has a fileoff (0x%" PRIx64 ") that extends beyond the end of the file (0x%" PRIx64 ")",
- i,
- lc_segment_name,
- load_cmd.fileoff,
- m_length);
+ module_sp->ReportError("is a corrupt mach-o file: load command %u %s has a fileoff (0x%" PRIx64 ") that extends beyond the end of the file (0x%" PRIx64 ")",
+ i,
+ lc_segment_name,
+ load_cmd.fileoff,
+ m_length);
load_cmd.fileoff = 0;
load_cmd.filesize = 0;
@@ -1053,11 +1053,11 @@ ObjectFileMachO::CreateSections (SectionList &unified_section_list)
// is null out the SectionList vector and if a process has been set up, dump a message
// to stdout. The most common case here is core file debugging with a truncated file.
const char *lc_segment_name = load_cmd.cmd == LoadCommandSegment64 ? "LC_SEGMENT_64" : "LC_SEGMENT";
- GetModule()->ReportError("is a corrupt mach-o file: load command %u %s has a fileoff + filesize (0x%" PRIx64 ") that extends beyond the end of the file (0x%" PRIx64 "), the segment will be truncated",
- i,
- lc_segment_name,
- load_cmd.fileoff + load_cmd.filesize,
- m_length);
+ module_sp->ReportError("is a corrupt mach-o file: load command %u %s has a fileoff + filesize (0x%" PRIx64 ") that extends beyond the end of the file (0x%" PRIx64 "), the segment will be truncated",
+ i,
+ lc_segment_name,
+ load_cmd.fileoff + load_cmd.filesize,
+ m_length);
// Tuncase the length
load_cmd.filesize = m_length - load_cmd.fileoff;
@@ -1095,6 +1095,20 @@ ObjectFileMachO::CreateSections (SectionList &unified_section_list)
}
else if (unified_section_sp)
{
+ if (is_dsym && unified_section_sp->GetFileAddress() != load_cmd.vmaddr)
+ {
+ // Check to see if the module was read from memory?
+ if (module_sp->GetObjectFile()->GetHeaderAddress().IsValid())
+ {
+ // We have a module that is in memory and needs to have its
+ // file address adjusted. We need to do this because when we
+ // load a file from memory, its addresses will be slid already,
+ // yet the addresses in the new symbol file will still be unslid.
+ // Since everything is stored as section offset, this shouldn't
+ // cause any problems.
+ unified_section_sp->SetFileAddress(load_cmd.vmaddr);
+ }
+ }
m_sections_ap->AddSection(unified_section_sp);
}
OpenPOWER on IntegriCloud