maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Object/macho-invalid.test

115 lines
8.7 KiB
Plaintext
Raw Normal View History

Update the comments for the macho-invalid-zero-ncmds test and fix llvm-objdump when printing the Mach Header to print the unknown cputype and cpusubtype fields as decimal instead of not printing them at all. And change the test to check for that. llvm-svn: 258826
2016-01-27 02:20:49 +08:00
// An odd Mach-O file, with just a mach header with all but the magic field
// and filetype zeros. The cputype and cpusubtype fields being zero are invalid,
// but that does not mater for the most part to display some of the contents.
RUN: llvm-objdump -private-headers %p/Inputs/macho-invalid-zero-ncmds -macho \
RUN: | FileCheck -check-prefix ZERO-NCMDS %s
ZERO-NCMDS: MH_MAGIC_64 0 0 0x00 OBJECT 0 0 0x00000000
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
2016-04-07 06:14:09 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho64-invalid-incomplete-load-command 2>&1 \
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: | FileCheck -check-prefix INCOMPLETE-LOADC %s
Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
2016-04-07 06:14:09 +08:00
INCOMPLETE-LOADC: truncated or malformed object (load command 0 extends past the end all load commands in the file)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
Produce another specific error message for a malformed Mach-O file when a load command other than the first one is past the end of the load commands. This is like the test case in test/Object/macho-invalid.test for macho64-invalid-incomplete-load-command but it is the second load command that is past the end of all the load commands instead of the first. The code in the constructor for MachOObjectFile that loops over the load commands used getNextLoadCommandInfo() which was not producing a good error message. So that was fixed and a test case was added. llvm-svn: 268403
2016-05-04 01:16:08 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho64-invalid-incomplete-load-command.1 2>&1 \
RUN: | FileCheck -check-prefix INCOMPLETE-LOADC-1 %s
INCOMPLETE-LOADC-1: truncated or malformed object (load command 1 extends past the end all load commands in the file)
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho-invalid-too-small-load-command 2>&1 \
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: | FileCheck -check-prefix SMALL-LOADC-SIZE %s
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho64-invalid-too-small-load-command 2>&1 \
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: | FileCheck -check-prefix SMALL-LOADC-SIZE %s
Fix a typo in an error message. Caught by Sean Silva! llvm-svn: 267056
2016-04-22 05:20:40 +08:00
SMALL-LOADC-SIZE: truncated or malformed object (load commands extend past the end of the file)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
Produce another specific error message for a malformed Mach-O file when a load command has a size less than 8 bytes. I think the existing test case in test/Object/macho-invalid.test for macho64-invalid-too-small-load-command was trying to test for this but that test case triggered a different error given how it was constructed. So I constructed a new test case that would trigger this specific error. I also changed the error message to be consistent with the other malformed Mach-O file error messages. I also removed object_error::macho_small_load_command from Object/Error.h as it is not needed and can just use object_error::parse_failed and let the error message string distinguish the error. llvm-svn: 268463
2016-05-04 07:13:50 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho64-invalid-too-small-load-command.1 2>&1 \
RUN: | FileCheck -check-prefix SMALL-LOADC-SIZE-1 %s
SMALL-LOADC-SIZE-1: truncated or malformed object (load command 1 with size less than 8 bytes)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: not llvm-objdump -private-headers %p/Inputs/macho-invalid-too-small-segment-load-command 2>&1 \
Add checks to the MachOObjectFile() constructor to make sure load commands sizes are the correct multiple. llvm-svn: 274798
2016-07-08 06:11:42 +08:00
RUN: | FileCheck -check-prefix MULTIPLE-NOT-4 %s
MULTIPLE-NOT-4: truncated or malformed object (load command 0 cmdsize not a multiple of 4)
Clean up the specific error message for a malformed Mach-O files with bad segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
2016-05-06 01:43:35 +08:00
RUN: not llvm-objdump -private-headers %p/Inputs/macho-invalid-too-small-segment-load-command.1 2>&1 \
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: | FileCheck -check-prefix SMALL-SEGLOADC-SIZE %s
Clean up the specific error message for a malformed Mach-O files with bad segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
2016-05-06 01:43:35 +08:00
SMALL-SEGLOADC-SIZE: truncated or malformed object (load command 0 LC_SEGMENT cmdsize too small)
Add checks to the MachOObjectFile() constructor to make sure load commands sizes are the correct multiple. llvm-svn: 274798
2016-07-08 06:11:42 +08:00
Clean up the specific error message for a malformed Mach-O files with bad segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
2016-05-06 01:43:35 +08:00
RUN: not llvm-objdump -private-headers %p/Inputs/macho64-invalid-too-small-segment-load-command 2>&1 \
Add checks to the MachOObjectFile() constructor to make sure load commands sizes are the correct multiple. llvm-svn: 274798
2016-07-08 06:11:42 +08:00
RUN: | FileCheck -check-prefix MULTIPLE-NOT-8 %s
MULTIPLE-NOT-8: truncated or malformed object (load command 0 cmdsize not a multiple of 8)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: not llvm-objdump -private-headers %p/Inputs/macho-invalid-no-size-for-sections 2>&1 \
RUN: | FileCheck -check-prefix TOO-MANY-SECTS %s
Clean up the specific error message for a malformed Mach-O files with bad segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
2016-05-06 01:43:35 +08:00
TOO-MANY-SECTS: truncated or malformed object (load command 0 inconsistent cmdsize in LC_SEGMENT for the number of sections)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: not llvm-objdump -private-headers %p/Inputs/macho64-invalid-no-size-for-sections 2>&1 \
Clean up the specific error message for a malformed Mach-O files with bad segment load commands. The existing test case in test/Object/macho-invalid.test for macho-invalid-too-small-segment-load-command has a cmdsize of 55, while being too small also it is not a multiple of 4. So when that check is added this test case will produce a different error. So I constructed a new test case that will trigger the intended error. I also changed the error message to be consistent with the other malformed Mach-O file error messages which prints the load command index. I also removed both object_error::macho_load_segment_too_small and object_error::macho_load_segment_too_many_sections from Object/Error.h as they are not needed and can just use object_error::parse_failed and let the error message string distinguish the specific error. llvm-svn: 268652
2016-05-06 01:43:35 +08:00
RUN: | FileCheck -check-prefix TOO-MANY-SECTS-64 %s
TOO-MANY-SECTS-64: truncated or malformed object (load command 0 inconsistent cmdsize in LC_SEGMENT_64 for the number of sections)
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
RUN: not llvm-objdump -macho -t %p/Inputs/macho-invalid-bad-symbol-index 2>&1 \
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: | FileCheck -check-prefix BAD-SYMBOL %s
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
BAD-SYMBOL: truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table)
RUN: llvm-objdump -macho -t %p/Inputs/macho-valid-0-nsyms 2>&1 \
Fix the code that leads to the incorrect trigger of the report_fatal_error() in MachOObjectFile::getSymbolByIndex() when a Mach-O file has a symbol table load command but the number of symbols are zero. The code in MachOObjectFile::symbol_begin_impl() should not be assuming there is a symbol at index 0, in cases there is no symbol table load command or the count of symbol is zero. So I also fixed that. And needed to fix MachOObjectFile::symbol_end_impl() to also do the same thing for no symbol table or one with zero entries. The code in MachOObjectFile::getSymbolByIndex() should trigger the report_fatal_error() for programmatic errors for any index when there is no symbol table load command and not return the end iterator. So also fixed that. Note there is no test case as this is a programmatic error. The test case using the file macho-invalid-bad-symbol-index has a symbol table load command with its number of symbols (nsyms) is zero. Which was incorrectly testing the bad triggering of the report_fatal_error() in in MachOObjectFile::getSymbolByIndex(). This test case is an invalid Mach-O file but not for that reason. It appears this Mach-O file use to have an nsyms value of 11, and what makes this Mach-O file invalid is the counts and indexes into the symbol table of the dynamic load command are now invalid because the number of symbol table entries (nsyms) is now zero. Which can be seen with the existing llvm-obdump: % llvm-objdump -private-headers macho-invalid-bad-symbol-index … Load command 4 cmd LC_SYMTAB cmdsize 24 symoff 4216 nsyms 0 stroff 4392 strsize 144 Load command 5 cmd LC_DYSYMTAB cmdsize 80 ilocalsym 0 nlocalsym 8 (past the end of the symbol table) iextdefsym 8 (greater than the number of symbols) nextdefsym 2 (past the end of the symbol table) iundefsym 10 (greater than the number of symbols) nundefsym 1 (past the end of the symbol table) ... And the native darwin tools generates an error for this file: % nm macho-invalid-bad-symbol-index nm: object: macho-invalid-bad-symbol-index truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table) I added new checks for the indexes and sizes for these in the constructor of MachOObjectFile. And added comments for what would be a proper diagnostic messages. And changed the test case using macho-invalid-bad-symbol-index to test for the new error now produced. Also added a test with a valid Mach-O file with a symbol table load command where the number of symbols is zero that shows the report_fatal_error() is not called. llvm-svn: 258576
2016-01-23 06:49:55 +08:00
RUN: | FileCheck -check-prefix ZERO-NSYMS %s
ZERO-NSYMS: SYMBOL TABLE
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
RUN: not llvm-objdump -t %p/Inputs/macho-invalid-symbol-name-past-eof 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF %s
Thread Expected<...> up from libObject’s getName() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 266919
2016-04-21 05:24:34 +08:00
NAME-PAST-EOF: truncated or malformed object (bad string index: 4261412866 for symbol at index 0)
Fix MachOObjectFile::getSymbolName() to not call report_fatal_error() but to return object_error::parse_failed.  Then made the code in llvm-nm do for Mach-O files what is done in the darwin native tools which is to print "bad string index" for bad string indexes. Updated the error message in the llvm-objdump test, and added tests to show llvm-nm prints "bad string index" and a test to print the actual bad string index value which in this case is 0xfe000002 when printing the fields as raw hex. llvm-svn: 258520
2016-01-23 02:47:14 +08:00
RUN: llvm-nm -pa %p/Inputs/macho-invalid-symbol-name-past-eof 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF-nm-pa %s
NAME-PAST-EOF-nm-pa: 0000000000000000 - 00 0000 SO bad string index
RUN: llvm-nm -pax %p/Inputs/macho-invalid-symbol-name-past-eof 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF-nm-pax %s
NAME-PAST-EOF-nm-pax: 0000000000000000 64 00 0000 fe000002 bad string index
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error when the object is in an archive to use something like libx.a(foo.o) as part of the error message. Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object files in archives and not produce any error message. To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting this interface to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in one place yet to be fully converted. Again there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comments for those. llvm-svn: 269784
2016-05-18 01:10:12 +08:00
RUN: not llvm-objdump -t %p/Inputs/macho-bad-archive1.a 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF-ARCHIVE %s
NAME-PAST-EOF-ARCHIVE: macho-bad-archive1.a(macho-invalid-symbol-name-past-eof) truncated or malformed object (bad string index: 4261412866 for symbol at index 0)
Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error when the object is from a slice of a Mach-O Universal Binary use something like "foo.o (for architecture i386)" as part of the error message when expected. Also fixed places in these tools that were ignoring object file errors from MachOUniversalBinary::getAsObjectFile() when the code moved on to see if the slice was an archive. To do this MachOUniversalBinary::getAsObjectFile() and MachOUniversalBinary::getObjectForArch() were changed from returning ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in two places yet to be fully converted. llvm-svn: 271332
2016-06-01 04:35:34 +08:00
RUN: not llvm-objdump -macho -arch all -t %p/Inputs/macho-universal-bad1.x86_64.i386 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF-FAT %s
NAME-PAST-EOF-FAT: macho-universal-bad1.x86_64.i386 (for architecture x86_64) truncated or malformed object (bad string index: 4261412866 for symbol at index 0)
RUN: not llvm-objdump -macho -arch all -t %p/Inputs/macho-universal-archive-bad1.x86_64.i386 2>&1 \
RUN: | FileCheck -check-prefix NAME-PAST-EOF-FAT-ARCHIVE %s
NAME-PAST-EOF-FAT-ARCHIVE: macho-universal-archive-bad1.x86_64.i386(macho-invalid-symbol-name-past-eof) (for architecture x86_64) truncated or malformed object (bad string index: 4261412866 for symbol at index 0)
Fix MachOObjectFile::getSymbolSection() to not call report_fatal_error() but to return object_error::parse_failed.  Then made the code in llvm-nm do for Mach-O files what is done in the darwin native tools which is to print "(?,?)" or just "s" for bad section indexes. Also added a test to show it prints the bad section index of "42" when printing the fields as raw hex. llvm-svn: 258434
2016-01-22 05:13:27 +08:00
RUN: llvm-nm %p/Inputs/macho-invalid-section-index-getSectionRawName 2>&1 \
Detect invalid section indexes when we first read them. We still detect the same errors, but now we do it earlier. llvm-svn: 238024
2015-05-22 22:59:27 +08:00
RUN: | FileCheck -check-prefix INVALID-SECTION-IDX-SYMBOL-SEC %s
Fix MachOObjectFile::getSymbolSection() to not call report_fatal_error() but to return object_error::parse_failed.  Then made the code in llvm-nm do for Mach-O files what is done in the darwin native tools which is to print "(?,?)" or just "s" for bad section indexes. Also added a test to show it prints the bad section index of "42" when printing the fields as raw hex. llvm-svn: 258434
2016-01-22 05:13:27 +08:00
INVALID-SECTION-IDX-SYMBOL-SEC: 0000000100000000 S __mh_execute_header
RUN: llvm-nm -m %p/Inputs/macho-invalid-section-index-getSectionRawName 2>&1 \
RUN: | FileCheck -check-prefix INVALID-SECTION-IDX-SYMBOL-SEC-m %s
INVALID-SECTION-IDX-SYMBOL-SEC-m: 0000000100000000 (?,?) [referenced dynamically] external __mh_execute_header
RUN: llvm-nm -pax %p/Inputs/macho-invalid-section-index-getSectionRawName 2>&1 \
RUN: | FileCheck -check-prefix INVALID-SECTION-IDX-SYMBOL-SEC-pax %s
INVALID-SECTION-IDX-SYMBOL-SEC-pax: 0000000100000000 0f 42 0010 00000065 __mh_execute_header
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
2016-03-24 04:27:00 +08:00
RUN: not llvm-objdump -t %p/Inputs/macho-invalid-section-index-getSectionRawName 2>&1 \
RUN: | FileCheck -check-prefix INVALID-SECTION-IDX-SYMBOL-SEC-objdump %s
Thread Expected<...> up from libObject’s getType() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: "// TODO: Actually report errors helpfully" and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
2016-05-03 04:28:12 +08:00
INVALID-SECTION-IDX-SYMBOL-SEC-objdump: truncated or malformed object (bad section index: 66 for symbol at index 8)
[Object, MachO] Don't crash on parsing invalid MachO header. Summary: Instead, properly report this error from MachOObjectFile constructor. Test Plan: regression test suite Reviewers: rafael Subscribers: llvm-commits llvm-svn: 239078
2015-06-05 03:45:22 +08:00
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho-invalid-header 2>&1 | FileCheck -check-prefix INVALID-HEADER %s
INVALID-HEADER: The file was not recognized as a valid object file
[Object, MachO] Don't crash on incomplete MachO segment load commands. Report proper error code from MachOObjectFile constructor if we can't parse another segment load command (we already return a proper error if segment load command contents is suspicious). llvm-svn: 239109
2015-06-05 06:26:44 +08:00
Start to add real error messages for malformed Mach-O files. And update the existing test cases in test/Object/macho-invalid.test to use llvm-objdump with the -macho option to produce these error messages and stop producing the generic "Invalid data was encountered while parsing the file" message. Working from the beginning of the file, if the mach header is too large for the size of the file and then if the load commands that follow extend past the end of the file these two errors now generate correct error messages. Both of these have existing test cases in test/Object/macho-invalid.test . But the first with macho-invalid-header it will never trigger the error message "mach header extends past the end of the file" using any of the llvm tools as they all use identify_magic() which rejects files with the correct magic number that are too small in size. So I tested this by hacking that code and seeing the error message down in parseHeader() really does happen. So in case there is ever code in llvm that directly calls createMachOObjectFile() this error message will be correctly produced. The second error message of "load commands extends past the end of the file" is triggered by a number of existing tests cases in test/Object/macho-invalid.test . Also other tests trigger different error messages now like "ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table". There are two existing test cases that still get the "Invalid data was encountered ..." error messages that I will tackle next. But they will involve a bit of pluming an Expect<...> up through the call stack and I want to do those as separate changes. FYI, for those test cases that were trying to test specific errors that now get different errors I’ll fix those in follow on changes and create new test cases for those so they test the error they were meant to test. llvm-svn: 266248
2016-04-14 05:17:58 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho64-invalid-incomplete-segment-load-command 2>&1 | FileCheck -check-prefix INCOMPLETE-SEGMENT-LOADC %s
Fix a typo in an error message. Caught by Sean Silva! llvm-svn: 267056
2016-04-22 05:20:40 +08:00
INCOMPLETE-SEGMENT-LOADC: truncated or malformed object (load commands extend past the end of the file)
Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error when the object is in an archive to use something like libx.a(foo.o) as part of the error message. Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object files in archives and not produce any error message. To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting this interface to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in one place yet to be fully converted. Again there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comments for those. llvm-svn: 269784
2016-05-18 01:10:12 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho-bad-archive2.a 2>&1 | FileCheck -check-prefix INCOMPLETE-SEGMENT-LOADC-ARCHIVE %s
INCOMPLETE-SEGMENT-LOADC-ARCHIVE: macho-bad-archive2.a(macho64-invalid-incomplete-segment-load-command) truncated or malformed object (load commands extend past the end of the file)
Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error when the object is from a slice of a Mach-O Universal Binary use something like "foo.o (for architecture i386)" as part of the error message when expected. Also fixed places in these tools that were ignoring object file errors from MachOUniversalBinary::getAsObjectFile() when the code moved on to see if the slice was an archive. To do this MachOUniversalBinary::getAsObjectFile() and MachOUniversalBinary::getObjectForArch() were changed from returning ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in two places yet to be fully converted. llvm-svn: 271332
2016-06-01 04:35:34 +08:00
RUN: not llvm-objdump -macho -private-headers -arch all %p/Inputs/macho-universal-bad2.x86_64.i386 2>&1 | FileCheck -check-prefix INCOMPLETE-SEGMENT-LOADC-FAT %s
INCOMPLETE-SEGMENT-LOADC-FAT: macho-universal-bad2.x86_64.i386 (for architecture x86_64) truncated or malformed object (load commands extend past the end of the file)
RUN: not llvm-objdump -macho -private-headers -arch all %p/Inputs/macho-universal-archive-bad2.x86_64.i386 2>&1 | FileCheck -check-prefix INCOMPLETE-SEGMENT-LOADC-FAT-ARCHIVE %s
INCOMPLETE-SEGMENT-LOADC-FAT-ARCHIVE: macho-universal-archive-bad2.x86_64.i386(macho64-invalid-incomplete-segment-load-command) (for architecture x86_64) truncated or malformed object (load commands extend past the end of the file)
Change all but the last ErrorOr<...> use for MachOUniversalBinary to Expected<...> to allow a good error message to be produced. I added the one test case that the object file tools could produce an error message. The other two errors can’t be triggered if the input file is passed through sys::fs::identify_magic(). But the malformedError("bad magic number") does get triggered by the logic in llvm-dsymutil when dealing with a normal Mach-O file. The other "File too small ..." error would take a logic error currently to produce and is not tested for. llvm-svn: 273946
2016-06-28 05:39:39 +08:00
RUN: not llvm-objdump -macho -universal-headers %p/Inputs/macho-invalid-fat 2>&1 | FileCheck -check-prefix INVALID-FAT %s
INVALID-FAT: truncated or malformed fat file (fat_arch_64 structs would extend past the end of the file)
Finish cleaning up most of the error handling in libObject’s MachOUniversalBinary and its clients to use the new llvm::Error model for error handling. Changed getAsArchive() from ErrorOr<...> to Expected<...> so now all interfaces there use the new llvm::Error model for return values. In the two places it had if (!Parent) this is actually a program error so changed from returning errorCodeToError(object_error::parse_failed) to calling report_fatal_error() with a message. In getObjectForArch() added error messages to its two llvm::Error return values instead of returning errorCodeToError(object_error::arch_not_found) with no error message. For the llvm-obdump, llvm-nm and llvm-size clients since the only binary files in Mach-O Universal Binaries that are supported are Mach-O files or archives with Mach-O objects, updated their logic to generate an error when a slice contains something like an ELF binary instead of ignoring it. And added a test case for that. The last error stuff to be cleaned up for libObject’s MachOUniversalBinary is the use of errorOrToExpected(Archive::create(ObjBuffer)) which needs Archive::create() to be changed from ErrorOr<...> to Expected<...> first, which I’ll work on next. llvm-svn: 274079
2016-06-29 07:16:13 +08:00
RUN: not llvm-objdump -macho -private-headers -arch all %p/Inputs/macho-invalid-fat.obj.elf-x86_64 2>&1 | FileCheck -check-prefix INVALID-FAT-ELF %s
INVALID-FAT-ELF: Mach-O universal file: {{.*}}/macho-invalid-fat.obj.elf-x86_64 for architecture x86_64 is not a Mach-O file or an archive file
Add the first of what will be a long line of additional error checks for invalid Mach-O files. This is where an LC_SEGMENT load command has a fileoff field that extends past the end of the file. Also fix llvm-nm and llvm-size to remove the errorToErrorCode() call so error messages are printed. And needed to update a few test cases now that they do print the error messages just a bit differently. llvm-svn: 277845
2016-08-06 02:19:40 +08:00
RUN: not llvm-objdump -macho -private-headers %p/Inputs/macho-invalid-segment-fileoff 2>&1 | FileCheck -check-prefix INVALID-SEGMENT-FILEOFF %s
INVALID-SEGMENT-FILEOFF: macho-invalid-segment-fileoff': truncated or malformed object (load command 0 fileoff field in LC_SEGMENT extends past the end of the file)
RUN: not llvm-nm %p/Inputs/macho-invalid-segment-fileoff 2>&1 | FileCheck -check-prefix INVALID-SEGMENT-FILEOFF-NM %s
INVALID-SEGMENT-FILEOFF-NM: macho-invalid-segment-fileoff truncated or malformed object (load command 0 fileoff field in LC_SEGMENT extends past the end of the file)
RUN: not llvm-size %p/Inputs/macho-invalid-segment-fileoff 2>&1 | FileCheck -check-prefix INVALID-SEGMENT-FILEOFF-SIZE %s
INVALID-SEGMENT-FILEOFF-SIZE: macho-invalid-segment-fileoff truncated or malformed object (load command 0 fileoff field in LC_SEGMENT extends past the end of the file)