Shift an older “invalid file” test to get a consistent naming for these
tests.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Object/MachOObjectFile.cpp | ||
---|---|---|
302 ↗ | (On Diff #18067) | Maybe "Segment load command size is too small."? |
Optional bonus (can be another patch): include more information in the errors: Section index is XXX, but there are only YYY sections.
lib/Object/MachOObjectFile.cpp | ||
---|---|---|
45 ↗ | (On Diff #18067) | There are no tests for this one. Please add one or convert this to an assert. |
60 ↗ | (On Diff #18067) | Nit. maybe avoid this bit of duplicated with a small helper template function that takes a MachO::segment_command_64 or a MachO::segment_command? |
Rephrase error pointed out by majnemer
Added a test requested by Rafael
Rafael: Extracting that part of the function yields code that's a bit too convoluted. Check which version you prefer (or suggest other changes).
lib/Object/MachOObjectFile.cpp | ||
---|---|---|
55 ↗ | (On Diff #18129) | Maybe pass a "const SegmentCmd&"? |
2234 ↗ | (On Diff #18129) | Missing test. |
2244 ↗ | (On Diff #18129) | Missing test. |
test/Object/macho-invalid.test | ||
33 ↗ | (On Diff #18129) | There are 4 errors that would match " Invalid section index": Please make sure they are all covered. |
Hi Everyone,
My understanding is that the ELF writer is also used by the MCJIT engine when filling an object buffer with jitted code. In that context, I am wondering if the call to llvm::report_fatal_error() is the appropriate way to report the error. It has the effect of killing the entire host application simply because one LLVM module couldn¹t be jitted.
Of course, fatal errors and assertions should never occur! ;-) And, if they never occur, then there isn¹t any issue. Moreover, it is much better to exit the application after a proper error message has been emitted, then crashing on a segfault! So, this patch is definitely a step in the right direction.
On the other hand, report_fatal_error() has the unfortunate consequence of killing our application before our users have any chance of saving their work.
Thus, I am wondering if there would be a way to indicate to the MCJIT engine that an internal error occurred while jitting a particular LLVM module. The compilation of that module would abort, but the application would not exit.
Is that a legitimate concern ? Comments ?
Cheers,
Benoit
Benoit Belley
Sr Principal Developer
M&E-Product Development Group
Autodesk, Inc.
www.autodesk.com http://www.autodesk.com/
This review is for code that parses files and is primarily used by introspective tools like llvm-objdump and the like. The code you are referring is substantially different, I think that discussion belongs in a different thread from this one.
Thanks for taking the time to answer. My comment was by no-mean implying that I was requesting any immediate code change. I completely agree, as I mentioned, in my original comment, that calling report_fatal_error() is infinitely better than crashing on segfault.
I was under the impression that the Object reader would be used when using/implementing an MCJIT object cache. Is that the case ?
Benoit
From: Filipe Cabecinhas <filcab+llvm.phabricator@gmail.com<mailto:filcab+llvm.phabricator@gmail.com>>
Date: jeudi 15 janvier 2015 14:17
To: "reviews+D6945+public+88af01f8557bf636@reviews.llvm.org<mailto:reviews+D6945+public+88af01f8557bf636@reviews.llvm.org>" <reviews+D6945+public+88af01f8557bf636@reviews.llvm.org<mailto:reviews+D6945+public+88af01f8557bf636@reviews.llvm.org>>
Cc: "rafael.espindola@gmail.com<mailto:rafael.espindola@gmail.com>" <rafael.espindola@gmail.com<mailto:rafael.espindola@gmail.com>>, Benoit Belley <benoit.belley@autodesk.com<mailto:benoit.belley@autodesk.com>>, "david.majnemer@gmail.com<mailto:david.majnemer@gmail.com>" <david.majnemer@gmail.com<mailto:david.majnemer@gmail.com>>, "llvm-commits@cs.uiuc.edu<mailto:llvm-commits@cs.uiuc.edu>" <llvm-commits@cs.uiuc.edu<mailto:llvm-commits@cs.uiuc.edu>>
Subject: Re: [PATCH] Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files.
Hi Benoit,