Changed files:
config-ix.cmake: Enabled UBSan for MIPS32
sanitizer_stacktrace.cc: Program counter for MIPS32 is four byte aligned and a delay slot so subtracted PC by 8 for getting call site address.
cast-overflow.cpp: Added big endian support for this test case.
Details
Diff Detail
Event Timeline
lib/sanitizer_common/sanitizer_stacktrace.cc | ||
---|---|---|
26 | While not the subject of this code review, I have to say that the name of this function seems to be wrong. (otherwise, it needs some explanation in a form of a code comment) |
Changed files:
sanitizer_stacktrace.cc: Considering the delay slot in MIPS32 PC should be subtracted by 8.
ubsan_handlers.cc: __ubsan_handle_float_cast_overflow should give callers PC to handleFloatCastOverflow to print the correct location. Else it prints the location of call site to be in ubsan_handlers.cc itself.
cast-overflow.cpp: Added support for big endian machines to cast-overflow test case.
lib/ubsan/ubsan_handlers.cc | ||
---|---|---|
273 | please add spaces around '=' |
Also, I'd prefer samsonov@ to review ubsan-related changes. (Somehow I can't CC him here...)
test/ubsan/TestCases/Float/cast-overflow.cpp | ||
---|---|---|
57 | Why is this value different than the one for little endian? |
LGTM. Thanks!
Note that we don't have a MIPS bot, so we can't guarantee we won't accidentally break this arch.
test/ubsan/TestCases/Float/cast-overflow.cpp | ||
---|---|---|
20 | nit: put this #include before #include <stdint.h> |
Note that we don't have a MIPS bot, so we can't guarantee we won't accidentally break this arch.
I'm in the process of sorting out some kit for new buildbots. I'll add a sanitizer buildslave to the todo list.
While not the subject of this code review, I have to say that the name of this function seems to be wrong. (otherwise, it needs some explanation in a form of a code comment)
From what I read in the rest of the code, this is used to convert a return-address value into a call-site address, right?
If that is correct, I am puzzled with the ARM part which does nothing for non-thumb addresses.
Further, (if my understanding is still correct,) MIPS should follow SPARC case for MIPS32r1/r2, as there is a delay slot to be taken into account.
Last, just a comment that this code is likely to become more complex with compact branches in MIPS32r6, microMIPS, etc.