replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
This commit is contained in:
Jason Molenda 2013-08-16 03:20:42 +00:00
parent 2393799609
commit 20eb31b907
3 changed files with 45 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
lldb/include/lldb/Core/Section.h
View File

@ -193,6 +193,9 @@ public:
lldb::addr_t
GetFileAddress () const;
bool
SetFileAddress (lldb::addr_t file_addr);
lldb::addr_t
GetOffset () const;

18
lldb/source/Core/Section.cpp
View File

@ -98,6 +98,24 @@ Section::GetFileAddress () const
return m_file_addr;
}
bool
Section::SetFileAddress (lldb::addr_t file_addr)
{
SectionSP parent_sp (GetParent ());
if (parent_sp)
{
if (m_file_addr >= file_addr)
return parent_sp->SetFileAddress (m_file_addr - file_addr);
return false;
}
else
{
// This section has no parent, so m_file_addr is the file base address
m_file_addr = file_addr;
return true;
}
}
lldb::addr_t
Section::GetOffset () const
{

34
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
View File

@ -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);
}