This is an archive of the discontinued LLVM Phabricator instance.

Fix several issues around dwo symbol file handling
ClosedPublic

Authored by tberghammer on Sep 11 2015, 8:36 AM.

Details

Summary

Fix several issues around dwo symbol file handling

This change all dwo related test failure on Linux x86_64

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer retitled this revision from to Fix several issues around dwo symbol file handling.
tberghammer updated this object.
tberghammer added a reviewer: clayborg.
tberghammer added a subscriber: lldb-commits.
clayborg requested changes to this revision.Sep 14 2015, 10:13 AM
clayborg edited edge metadata.

Just can't check for zero in SymbolFileDWARF, other than that it looks good.

source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
2242–2248 ↗(On Diff #34550)

This actually can be zero for functions in a .o file. So this must be removed or you must fix it in a different way.

This revision now requires changes to proceed.Sep 14 2015, 10:13 AM

I meant can't check for zero function start address in DWARFASTParserClang.cpp.

tberghammer added inline comments.Sep 14 2015, 10:19 AM
source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
2242–2248 ↗(On Diff #34550)

Is there any case when the code is executed from the object file directly and not from the shared library? On Linux I am pretty sure it can't happen, but I am not sure about OSX.

If the function is executed from the shared library then the lowest_func_addr should be already offsetted by the object file base address at this point

I should clarify: mach-o files do have functions at zero and these are legal DWARF and we need to read this DWARF correctly. We might be able to ask the SymbolFile's ObjectFile about this address and if it can be a valid function address using:

AddressClass ObjectFile::GetAddressClass (lldb::addr_t file_addr);
source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
2243–2247 ↗(On Diff #34550)

We might be able to ask the SymbolFile's ObjectFile if zero can be a valid code address. Then this could would become:

if (lowest_func_addr == 0 && objfile->FileAddressIsValidForCode(lowest_func_addr)
{
}

Or we might be able to ask the address class of an address:

const AddressClass addr_class = obj_file->GetAddressClass (lowest_func_addr);
if (addr_class != eAddressClassCode && addr_class != eAddressClassCodeAlternateISA)
    return nullptr;

We would need to make sure that an address of zero in a mach-o .o file returns eAddressClassCode or eAddressClassCodeAlternateISA type.

Thank you for the clarification. I will commit in this patch without the change we discussed (ignoring 0 file address) and I will address that issue later.

This revision was automatically updated to reflect the committed changes.