From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 270333858CDB; Fri, 1 Dec 2023 10:40:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 270333858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701427235; bh=C9WHcgGBEsqL4pRqMVsp9fBYNuGQDgSGjpbt6Ulng2g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GFvek+/vNIFTic7Mtr5KClbXM9NOp0ERWox4AJFut1tfBNjhDBid6nMsPWJ/DyKMQ mGrEd9cyLjUPs8pgF5v/t/yfUu9UCEglaDOifLDI8lLe+20yXWOFF4rP1ZNpUmGCME i914Qtl/YLRnQc0HyI4lxL9FuOVF8+ihEckML2zI= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge Date: Fri, 01 Dec 2023 10:40:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: tnfchris at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112644 --- Comment #6 from Tamar Christina --- Matthew has been working on this and so far has concluded: Summary of main problem: New libhwasan runtime libraries have added interceptors for various mem*, s= tr* functions (and I think others -- I do not have full list). With old runtime libraries these were not intercepted, and we emitted inline instrumentation to accommodate. Removing our instrumentation is fine (though with the caveat that we need to ensure we have the full list of functions which are now intercepted). However, the libraries hard-code the choice to abort on error, which means = the HWASAN_OPTIONS environment variable can no longer be used to ensure recover= on error (-fsanitize-recover=3Dhwaddress option). Changes I believe should happen: - LLVM upstream libsanitizer code be changed to allow recovery -- AFAIK the= re is no functional loss from using ErrorAction::Recover in the checking. - We find the list of functions which are now instrumented, and update asan_instrumented_p accordingly (plus a testcase or two for this). The first one was discussed on the LLVM discourse and it was deemed a bug https://discourse.llvm.org/t/hwasan-question-about-the-recent-interceptors-= being-added/75351/4 and a PR made to fix it https://github.com/llvm/llvm-project/pull/74000 Once that's merged we can re-sync and we need to update the list of interce= pted functions in asan_intercepted_p (in gcc/asan.h). One of the reasons for the change is that LLVM now replaces calls to e.g. memset with __hwasan_memset = to avoid later passes optimizing the call. It looks like we need to do that f= or GCC as well. Matthew will be away for a while so will take over the patch from him in stage-4.=