From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31542 invoked by alias); 16 Jul 2009 22:32:25 -0000 Received: (qmail 31531 invoked by uid 22791); 16 Jul 2009 22:32:22 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Jul 2009 22:32:10 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n6GMW8ps012880; Thu, 16 Jul 2009 18:32:08 -0400 Received: from fche.csb (vpn-10-31.bos.redhat.com [10.16.10.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6GMW6XS001539; Thu, 16 Jul 2009 18:32:06 -0400 Received: by fche.csb (Postfix, from userid 2569) id 3D656584B9; Thu, 16 Jul 2009 18:31:57 -0400 (EDT) To: Ian Lance Taylor Cc: Janboe Ye , gcc@gcc.gnu.org, janboe.ye@gmail.com Subject: Re: how to use expand_builtin_alloca References: <1247519293.4414.16.camel@debian-nb> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 16 Jul 2009 22:32:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "Mon, 13 Jul 2009 14:17:35 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00324.txt.bz2 > Janboe Ye writes: >> normally gcc will use expand_builtin_alloca to handle variable array. >> But mudflap will force this function to return immediately to invoke >> alloca explicit. >> >> Is there some way to still use expand_builtin_alloca without changing >> gcc source code? I don't think so. Ian Lance Taylor writes: > mudflap can't check accesses to memory allocated using alloca unless > it overrides __builtin_alloca. It can't currently. But instead of redirecting the call to a heap-based alloca() wannabe in libmudflap/mf-hooks1.c, perhaps mudflap could instrument alloca() by generating code like this instead: __builtin_alloca(N) --> GIMPLE_TRY_FINALLY( try { ptr = __builtin_alloca(N) __mf_register(ptr ...) ptr; } finally (attached to the function scope) { __mf_unregister(ptr ...) } Or perhaps not, if alloca() can be used in loops in way that prevents clean nesting of the try/finally. OTOH, I believe the original poster's case came from gcc-synthesized alloca's, coming from variable-length array allocation. Those in turn might be represented with almost the normal mf_xform_decls(), while letting __builtin_alloca() remain. Either of these requires gcc changes though. > [...] Although, of course, you could simply not use mudflap for the > code in question. The original poster's purpose is specifically to build bits of the linux kernel with mudflap instrumentation. - FChE