Message ID | 20231208134950.14883-1-amonakov@ispras.ru |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5466255vqy; Fri, 8 Dec 2023 05:50:29 -0800 (PST) X-Google-Smtp-Source: AGHT+IEEgFpPp8HTqnBKVDWLnbG3sSo3s7A4T1a7uDuBWJ07laqSOXdG0YK4RleIhsp6DsHpex1u X-Received: by 2002:a05:620a:22cc:b0:77f:3301:5357 with SMTP id o12-20020a05620a22cc00b0077f33015357mr96731qki.43.1702043429467; Fri, 08 Dec 2023 05:50:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1702043429; cv=pass; d=google.com; s=arc-20160816; b=JJkwxS0jFtcn8sjtCKQnhePyauG4CzhM2EJ+pml2h/VSGkcCOfnB1A3jVvcK0sBlMX hanirox6/Mts5CY/tu6ocqJ9Go4AJCx4tEUEGCMY80pNuoiazbbvr+Q3SqQQf8laKJ5Z foUe556TR9B4ZDsUC8E4DxibwELU2jMBEC48T5oyRqrSuw6GSLjGMOg733P/uT8v72HM Le8anb8upU4nJdpX0m4CJ+LPegXqtKnUAPpNumlg7PJLuJoQDoUK0PgL//TahDbTt+7c 8/h8TpBYwhLr6/bj7piHH4ZyVk8Ou7s/Uu9XnzXDwyeneikr+PQZC0v6EBP9UHNvVlbb WUFQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:dkim-filter :arc-filter:dmarc-filter:delivered-to; bh=KcfF4+6Xrf0R2JSYP8OdhBe6xaHFccO6HljfC+dihFg=; fh=4aB4vQzPl2n5bcuCu4RgOBehRuc44+zSBu8dvfJzPXg=; b=oTdriIS1wWBClL9ChG4KNKUXOYLkzwHqgljMDHWsmNWd3J+thUUrrDqBNHW4fk60rK cDsc3B6eqTasFO/wLVy0aiWP/mw38FQo4z+GM8UtxOPm4wZu4wqf4LGj8UhOcVwOmZ9n RxSDkJ9XS8E1U8Wz+4inrybhEFSsBBLDLrWTac0ThpdXLw6EkEZ0dWsUCMtX5uGrCnD4 Pck9BjRHwBdYiRyGWrZNSAc61fFrhHgf8YWwOb4S7kce1pG2NcUEpvZB3q7E17ikrNg4 oK/djYZqDZ97TMG+CrIEkGYBNJ6W65Mio2S+k7scZXN1Hc8Sdkd/TWo7zA11AARc4vcL GhBg== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id u6-20020a05620a430600b0077d880e0bffsi2175021qko.389.2023.12.08.05.50.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 05:50:29 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3CEE0385771D for <ouuuleilei@gmail.com>; Fri, 8 Dec 2023 13:50:29 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 2BC233858C62 for <gcc-patches@gcc.gnu.org>; Fri, 8 Dec 2023 13:50:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2BC233858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2BC233858C62 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702043406; cv=none; b=luRcGd15FWrZjgCSl+GGQyNc+V55sC1EQ3J+bH1GjYb0lq5I9KzxfCnQ/rfQQbdbHNRwejBKN/8+vn5U8SilfwY0WbwV1tYfLZbaG+06unD4JDpX+/An056XKfDnnqj7v+owjklxeGP/4TiKeDhVOSGN1BQIIqfl1JpX2JAi3BE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702043406; c=relaxed/simple; bh=38QA5Iq6dmT14VtAXjOSBEDtsJ0o3lXl5P/qFciTDpk=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=W8HZ2QcOGaxDWmfpYf8MTVHn1CLwdtkI/Z01tSxv/fhm7Dt/+4DAzXs6YvSE2nwqcy17dv3REm6/dn9LRfq80Fsi4muEUiVjI2GVO+qORe2+Lg4Cr7xMTBsNF1H+ItbhqPlz8N6RH4a55HR87hZ8Cazyl1p4mncEgu1X/C3k+VM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost.intra.ispras.ru (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTP id 90B0B40F1DF1; Fri, 8 Dec 2023 13:50:00 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 90B0B40F1DF1 From: Alexander Monakov <amonakov@ispras.ru> To: gcc-patches@gcc.gnu.org Cc: =?utf-8?q?Arsen_Arsenovi=C4=87?= <arsen@gentoo.org>, Sam James <sam@gentoo.org>, Daniil Frolov <exactlywb@ispras.ru>, Alexander Monakov <amonakov@ispras.ru> Subject: [PATCH 0/1] Detecting lifetime-dse issues via Valgrind [PR66487] Date: Fri, 8 Dec 2023 16:49:49 +0300 Message-Id: <20231208134950.14883-1-amonakov@ispras.ru> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784721891045036912 X-GMAIL-MSGID: 1784721891045036912 |
Series |
Detecting lifetime-dse issues via Valgrind [PR66487]
|
|
Message
Alexander Monakov
Dec. 8, 2023, 1:49 p.m. UTC
I would like to propose Valgrind integration previously sent as RFC for trunk. Arsen and Sam, since you commented on the RFC I wonder if you can have a look at the proposed configure and documentation changes and let me know if they look fine for you? For reference, gccinstall.info will say: ‘--enable-valgrind-interop’ Provide wrappers for Valgrind client requests in libgcc, which are used for ‘-fvalgrind-annotations’. Requires Valgrind header files for the target (in the build-time sysroot if building a cross-compiler). and GCC manual will document the new option as: -fvalgrind-annotations Emit Valgrind client requests annotating object lifetime boundaries. This allows to detect attempts to access fields of a C++ object after its destructor has completed (but storage was not deallocated yet), or to initialize it in advance from "operator new" rather than the constructor. This instrumentation relies on presence of "__gcc_vgmc_make_mem_undefined" function that wraps the corresponding Valgrind client request. It is provided by libgcc when it is configured with --enable-valgrind-interop. Otherwise, you can implement it like this: #include <valgrind/memcheck.h> void __gcc_vgmc_make_mem_undefined (void *addr, size_t size) { VALGRIND_MAKE_MEM_UNDEFINED (addr, size); } Changes since the RFC: * Add documentation and tests. * Drop 'emit-' from -fvalgrind-emit-annotations. * Use --enable-valgrind-interop instead of overloading --enable-valgrind-annotations. * Do not build the wrapper unless --enable-valgrind-interop is given and Valgrind headers are present. * Clean up libgcc configure changes. * Reword comments. Daniil Frolov (1): object lifetime instrumentation for Valgrind [PR66487] gcc/Makefile.in | 1 + gcc/builtins.def | 3 + gcc/common.opt | 4 + gcc/doc/install.texi | 5 + gcc/doc/invoke.texi | 27 +++++ gcc/gimple-valgrind-interop.cc | 112 ++++++++++++++++++ gcc/passes.def | 1 + gcc/testsuite/g++.dg/valgrind-annotations-1.C | 22 ++++ gcc/testsuite/g++.dg/valgrind-annotations-2.C | 12 ++ gcc/tree-pass.h | 1 + libgcc/Makefile.in | 3 + libgcc/config.in | 6 + libgcc/configure | 22 +++- libgcc/configure.ac | 15 ++- libgcc/libgcc2.h | 2 + libgcc/valgrind-interop.c | 40 +++++++ 16 files changed, 274 insertions(+), 2 deletions(-) create mode 100644 gcc/gimple-valgrind-interop.cc create mode 100644 gcc/testsuite/g++.dg/valgrind-annotations-1.C create mode 100644 gcc/testsuite/g++.dg/valgrind-annotations-2.C create mode 100644 libgcc/valgrind-interop.c
Comments
On Fri, Dec 08, 2023 at 04:49:49PM +0300, Alexander Monakov wrote: > I would like to propose Valgrind integration previously sent as RFC for trunk. > > Arsen and Sam, since you commented on the RFC I wonder if you can have > a look at the proposed configure and documentation changes and let me > know if they look fine for you? For reference, gccinstall.info will say: Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented there? Wouldn't this be better done by emitting the sequence inline? Even if it is done in libgcc, it is part of ABI. So, basically add a new optab, valgrind_request, where each target would define_insn whatever is needed (it will need to be a single pattern, it can't be split among multiple) and sorry on -fvalgrind-annotations if the optab is not defined. Advantage would be that --enable-valgrind-interop nor building against valgrind headers is not needed. In your version, did the new function go just to libgcc.a or to libgcc_s.so.1? Having a function in there or not dependent on --enable-valgrind-interop would turn it into an ABI configure option. Jakub
On Fri, 8 Dec 2023, Jakub Jelinek wrote: > Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented > there? It seems Valgrind folks take binary compatibility seriously, so that sounds unlikely. > Wouldn't this be better done by emitting the sequence inline? > Even if it is done in libgcc, it is part of ABI. I'd rather keep it as simple as possible. We could drop the libgcc parts, users can drop in the wrapper as explained in the manual. > So, basically add a new optab, valgrind_request, where each target would > define_insn whatever is needed (it will need to be a single pattern, it > can't be split among multiple) and sorry on -fvalgrind-annotations if the > optab is not defined. There are going to be complications since the request needs a descriptor structure (on the stack), plus it needs more effort on the GCC side than Valgrind side (when Valgrind is ported to a new target). I'd rather not go that way. > Advantage would be that --enable-valgrind-interop nor building against > valgrind headers is not needed. Alternatively, how about synthesizing an auxiliary translation unit with the wrapper from the driver for -fvalgrind-annotations? > In your version, did the new function go just to libgcc.a or to > libgcc_s.so.1? It participates in libgcc_s link, but it's not listed in the version script, so it's not exported from libgcc_s (and -gc-sections should eliminate it). Alexander
On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote: > On Fri, 8 Dec 2023, Jakub Jelinek wrote: > > In your version, did the new function go just to libgcc.a or to > > libgcc_s.so.1? > > It participates in libgcc_s link, but it's not listed in the version script, > so it's not exported from libgcc_s (and -gc-sections should eliminate it). Then it at least should not participate in that link. There are various other objects which are libgcc.a only (e.g. all of dfp stuff, etc.). Jakub
On Fri, 8 Dec 2023, Jakub Jelinek wrote: > On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote: > > On Fri, 8 Dec 2023, Jakub Jelinek wrote: > > > In your version, did the new function go just to libgcc.a or to > > > libgcc_s.so.1? > > > > It participates in libgcc_s link, but it's not listed in the version script, > > so it's not exported from libgcc_s (and -gc-sections should eliminate it). > > Then it at least should not participate in that link. > There are various other objects which are libgcc.a only (e.g. all of dfp > stuff, etc.). Thanks, changing LIB2ADD += $(srcdir)/valgrind-interop.c to LIB2ADD_ST += $(srcdir)/valgrind-interop.c in my tree achieved that. Alexander