UBSan on AArch64

Kostya, Christophe,

I'm running the full tests on AARch64 and the only RT test that fails is:

UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp

The problem seems to be a trap in __sanitizer::internal_memchr() while
trying to handle __ubsan::__ubsan_handle_float_cast_overflow().

I haven't looked at it in detail, has anyone seen this? Is UBSan meant
to run on AArch64? Should we mark this test XFAIL until it can be
looked at properly?

cheers,
--renato

Kostya, Christophe,

I'm running the full tests on AARch64 and the only RT test that fails is:

UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp

The problem seems to be a trap in __sanitizer::internal_memchr() while
trying to handle __ubsan::__ubsan_handle_float_cast_overflow().

I haven't looked at it in detail, has anyone seen this? Is UBSan meant
to run on AArch64? Should we mark this test XFAIL until it can be
looked at properly?

I was focusing on ASan, so I didn't look at UBSan. Sorry to have no clue.

Kostya, Christophe,

I'm running the full tests on AARch64 and the only RT test that fails is:

UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp

The problem seems to be a trap in __sanitizer::internal_memchr() while
trying to handle __ubsan::__ubsan_handle_float_cast_overflow().

Can you give more info (exact report, gdb trace, etc)

I haven't looked at it in detail, has anyone seen this? Is UBSan meant
to run on AArch64?

We never tried, but there is very little platform dependent code in UBSan.

Should we mark this test XFAIL until it can be
looked at properly?

Ideally no, but if this is blocking you and there is no quick fix, please
add something like
XFAIL: aarch64 (not sure about the exact syntax)

Can you give more info (exact report, gdb trace, etc)

It's not that simple, as the actual failure is down the service
routine, which only triggers way down the execution line, so stepping
through it is not trivial. One would have to know what to expect (ie.
know the UBsan code, setthe right breakpoints) and step through on
AArch64 directly. Unfortunately, I can't give you access to that
machine. :frowning:

We never tried, but there is very little platform dependent code in UBSan.

Maybe I should disable it. the thing is that I want to get a baseline,
where we can start from a green bot. Marking as XFAIL is one way to
document that "this should pass", instead of UNSUPPORTED, which
shouldn't. Since it's already marked as XFAIL for ARM, I'm guessing
one fix should help both archs.

cheers,
--renato

> Can you give more info (exact report, gdb trace, etc)

It's not that simple, as the actual failure is down the service
routine, which only triggers way down the execution line, so stepping
through it is not trivial. One would have to know what to expect (ie.
know the UBsan code, setthe right breakpoints) and step through on
AArch64 directly. Unfortunately, I can't give you access to that
machine. :frowning:

Can you at least grab a backtrace on the trap instruction? (or is there
weird stack stuff going on?)

-- Sean Silva

> Can you give more info (exact report, gdb trace, etc)

It's not that simple, as the actual failure is down the service
routine, which only triggers way down the execution line, so stepping
through it is not trivial. One would have to know what to expect (ie.
know the UBsan code, setthe right breakpoints) and step through on
AArch64 directly. Unfortunately, I can't give you access to that
machine. :frowning:

> We never tried, but there is very little platform dependent code in
UBSan.

Maybe I should disable it. the thing is that I want to get a baseline,
where we can start from a green bot. Marking as XFAIL is one way to
document that "this should pass", instead of UNSUPPORTED, which
shouldn't. Since it's already marked as XFAIL for ARM, I'm guessing
one fix should help both archs.

Yep, makes sense, feel free to add XFAIL: aarch64 (or equivalent)