At the moment errors in relocation processing such as out of range
values are not detected or at best trapped by asserts which will not
be present in release builds. This patch adds support for checking
error return values from applyRelocation() calls and printing an
appropriate error message. It also adds support for printing multiple
errors rather than just the first one.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/ReaderWriter/ELF/SectionChunks.h | ||
---|---|---|
426 | Now parallel_for_each does all tasks in the single thread. But in the future the body of this loop can be parallelized. Does the printError ready to be called from multiple threads? |
Thanks for working on this, it is certainly something that we should handle better. Would it be possible for you to split this up into two patches? One introducing the error and a second actually making use of it in the AArch64 backend to perform range checks?
lib/Core/Error.cpp | ||
---|---|---|
122 ↗ | (On Diff #17761) | I think we should move this error category inside ELF. |
lib/Core/Error.cpp | ||
---|---|---|
122 ↗ | (On Diff #17761) | Is there a strong reason to do so? I can see this error category being useful for the PE/COFF backend as well. There are a few relocations in the ARM target that are limited, and it would be nice to be able to return an error instead of asserting that the target is in range. |
lib/Core/Error.cpp | ||
---|---|---|
122 ↗ | (On Diff #17761) | Sounds good then. |
- Split out AArch64 ABS32 overflow checking code to a separate patch
- Add a mutex to make sure error output it not interleaved when multi-threaded
lib/Core/Error.cpp | ||
---|---|---|
123 ↗ | (On Diff #17859) | Instead of adding a new error category for your purpose, I think it would be better to just use make_dynamic_error_code(). It's simpler to use. |
lib/ReaderWriter/ELF/SectionChunks.h | ||
285 | This doesn't seems a correct way to use Twine. This should be (Twine(errorStr) + "in file " ...).str() instead of Twine(errorStr + "in file " ...).str() |
Switched to using dynamic error rather than adding a new error category.
Fixed buggy usage of Twine.
Your concern is a legitimate one, but it's also not specific to this
patch. The JIT generally makes very little effort to report gracefully
when a compile fails. The current philosophy is more or less that the
frontend is expected to generate IR that is valid to compile; if it
doesn't, that's a fatal bug in the frontend. There is a desire to
change that, but no one has really volunteered to take that on.
Philip
This doesn't seems a correct way to use Twine. This should be
instead of