On 26.04.2019 09:31, Andreas Gustafsson wrote: >>> port-sparc/53277: Many ubsan tests fail on sparc >> Re-test after >> https://v4.freshbsd.org/commit/netbsd/src/eTZNaSjDaT7KUvjB > These are still failing. This was assigned to me, my code in sanitizers is in GCC9 and the GCC7 implementation is mostly independent from my work (initial code of my work landed to GCC7, more of into GCC8 and almost all of it into GCC9). I was trying setup sparc and sparc64 in qemu (4.0.0nb4), but both of them hang during the install process when unpacking sets. Is it known? releng machines for sparc and sparc64 seem to be offline for long time now. At least, I'm not able to check the reports on the releng.netbsd.org site. UBSan is relatively independent from OS/kernel. The main two things that are platform dependent are: 1. syscall(2)/__syscall(2) calls wrapping syscalls. This code is still used in GCC7-for-NetBSD and no longer in GCC9-for-NetBSD (as I've switched it to libc calls). I've noted various issues with misusing syscall/__syscall in the NetBSD GCC7 code. 2. Reading PC/FP/SP from ucontext. The 2nd part has been addressed and already synced with GCC9. For the 1st part I've introduced fixups backporting corrections from LLVM compiler-rt from October 1st 2018, from the day of switching LLVM compiler-rt calls to libc. Backporting this switch and other improvements to downstream GCC is too invasive and better to wait for GCC upgrade. Please recheck sparc and sparc64 with: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_linux.cc r.1.30
Attachment:
signature.asc
Description: OpenPGP digital signature