Fix a crash in running llvm-objdump -t with an invalid Mach-O file already
authorKevin Enderby <enderby@apple.com>
Wed, 23 Mar 2016 20:27:00 +0000 (20:27 +0000)
committerKevin Enderby <enderby@apple.com>
Wed, 23 Mar 2016 20:27:00 +0000 (20:27 +0000)
commit5afbc1cda7a63bf3084e4fc9d74d5530ca8acfd9
tree9b10fac304d4de4e1927c51d5dcc3c9a909f2000
parent7876f180b5fde2ecf3216a7a2800bdbd234f2fcd
Fix a crash in running llvm-objdump -t with an invalid Mach-O file already
in the test suite. While this is not really an interesting tool and option to run
on a Mach-O file to show the symbol table in a generic libObject format
it shouldn’t crash.

The reason for the crash was in MachOObjectFile::getSymbolType() when it was
calling MachOObjectFile::getSymbolSection() without checking its return value
for the error case.

What makes this fix require a fair bit of diffs is that the method getSymbolType() is
in the class ObjectFile defined without an ErrorOr<> so I needed to add that all
the sub classes.  And all of the uses needed to be updated and the return value
needed to be checked for the error case.

The MachOObjectFile version of getSymbolType() “can” get an error in trying to
come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol
symbol type is an N_SECT type because the code is trying to select from the
SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type.
And it needs the Mach-O section to use isData() and isBSS to determine if
it will return SymbolRef::ST_Data.

One other possible fix I considered is to simply return SymbolRef::ST_Other
when MachOObjectFile::getSymbolSection() returned an error.  But since in
the past when I did such changes that “ate an error in the libObject code” I
was asked instead to push the error out of the libObject code I chose not
to implement the fix this way.

As currently written both the COFF and ELF versions of getSymbolType()
can’t get an error.  But if isReservedSectionNumber() wanted to check for
the two known negative values rather than allowing all negative values or
the code wanted to add the same check as in getSymbolAddress() to use
getSection() and check for the error then these versions of getSymbolType()
could return errors.

At the end of the day the error printed now is the generic “Invalid data was
encountered while parsing the file” for object_error::parse_failed.  In the
future when we thread Lang’s new TypedError for recoverable error handling
though libObject this will improve.  And where the added // Diagnostic(…
comment is, it would be changed to produce and error message
like “bad section index (42) for symbol at index 8” for this case.

llvm-svn: 264187
15 files changed:
llvm/include/llvm/Object/COFF.h
llvm/include/llvm/Object/ELFObjectFile.h
llvm/include/llvm/Object/MachO.h
llvm/include/llvm/Object/ObjectFile.h
llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp
llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp
llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
llvm/lib/Object/COFFObjectFile.cpp
llvm/lib/Object/MachOObjectFile.cpp
llvm/test/Object/macho-invalid.test
llvm/tools/dsymutil/MachODebugMapParser.cpp
llvm/tools/llvm-objdump/MachODump.cpp
llvm/tools/llvm-objdump/llvm-objdump.cpp
llvm/tools/llvm-readobj/ARMWinEHPrinter.cpp
llvm/tools/llvm-rtdyld/llvm-rtdyld.cpp