From patchwork Wed Dec 5 16:12:18 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 203899 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 00AD82C00A9 for ; Thu, 6 Dec 2012 03:12:39 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1355328760; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=XqfuTCpxSQNW55L1mxuo VYwr0Ok=; b=EgBWEAHnM0ecWHVQVshkSZgsxokbgCEZVM92RwjQ3DP2JcqgDJvb j4xnWEBozvYy1oAFi6+MQm0xt3HgT62H5ZQMS+w3AlKoR8Fi8RB5rorvqePH51T1 ayscWxbUMPlArLcZh4zzmiISMYpImRrT7ZQBO25QV3E34ZVzNyE9IHM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=jkKmZ572Pd+bdKSyE2+t2mQOj220VzmbEldmLz7OpHyCBCektYqnj/ZjJdja91 9dtCBZxPHOgEPEPSnXOp6IBBWIvCuoiUQ7UYKRF5Fz4xWJTtfqXhM6kcL7B8VjZs bzWu0mwEtJUoQ0ef1PdRZLZ6C70AhUEZ7FxP4RwdLSJQ4=; Received: (qmail 11492 invoked by alias); 5 Dec 2012 16:12:33 -0000 Received: (qmail 11477 invoked by uid 22791); 5 Dec 2012 16:12:31 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Dec 2012 16:12:22 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB5GCM1m002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2012 11:12:22 -0500 Received: from zalov.redhat.com (vpn1-5-46.ams2.redhat.com [10.36.5.46]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qB5GCK7a027156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 11:12:21 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qB5GCJdt005239; Wed, 5 Dec 2012 17:12:19 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qB5GCJkN005238; Wed, 5 Dec 2012 17:12:19 +0100 Date: Wed, 5 Dec 2012 17:12:18 +0100 From: Jakub Jelinek To: Richard Biener , Konstantin Serebryany , Dodji Seketeli Cc: gcc-patches@gcc.gnu.org Subject: [asan] Handle bitfields in asan Message-ID: <20121205161218.GY2315@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! This patch tries to handle bitfield accesses as if it were writes/reads from the corresponding DECL_BIT_FIELD_REPRESENTATIVE. Richard, does it make sense this way (the code will take ADDR_EXPR of the COMPONENT_REF with the DECL_BIT_FIELD_REPRESENTATIVE and use the size of the representative if it decides to instrument it. Fixes the first 4 asan_test.C failures. Ok for trunk? 2012-12-05 Jakub Jelinek * asan.c (instrument_derefs): Handle bitfield COMPONENT_REFs accesses as reads/writes to their DECL_BIT_FIELD_REPRESENTATIVE. Jakub --- gcc/asan.c.jj 2012-12-05 15:30:56.000000000 +0100 +++ gcc/asan.c 2012-12-05 17:00:56.957641944 +0100 @@ -792,9 +792,6 @@ instrument_derefs (gimple_stmt_iterator || (unsigned HOST_WIDE_INT) size_in_bytes - 1 >= 16) return; - /* For now just avoid instrumenting bit field acceses. - Fixing it is doable, but expected to be messy. */ - HOST_WIDE_INT bitsize, bitpos; tree offset; enum machine_mode mode; @@ -803,7 +800,17 @@ instrument_derefs (gimple_stmt_iterator &mode, &unsignedp, &volatilep, false); if (bitpos % (size_in_bytes * BITS_PER_UNIT) || bitsize != size_in_bytes * BITS_PER_UNIT) - return; + { + if (TREE_CODE (t) == COMPONENT_REF + && DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1)) != NULL_TREE) + { + tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1)); + instrument_derefs (iter, build3 (COMPONENT_REF, TREE_TYPE (repr), + TREE_OPERAND (t, 0), repr, + NULL_TREE), location, is_store); + } + return; + } base = build_fold_addr_expr (t); build_check_stmt (location, base, iter, /*before_p=*/true,