From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14279 invoked by alias); 19 Jul 2009 20:08:57 -0000 Received: (qmail 14267 invoked by uid 22791); 19 Jul 2009 20:08:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f177.google.com (HELO mail-px0-f177.google.com) (209.85.216.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Jul 2009 20:08:47 +0000 Received: by pxi7 with SMTP id 7so1365680pxi.0 for ; Sun, 19 Jul 2009 13:08:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.242.11 with SMTP id p11mr781213wfh.221.1248034126012; Sun, 19 Jul 2009 13:08:46 -0700 (PDT) In-Reply-To: References: <1247519293.4414.16.camel@debian-nb> Date: Sun, 19 Jul 2009 20:08:00 -0000 Message-ID: Subject: Re: how to use expand_builtin_alloca From: ye janboe To: "Frank Ch. Eigler" Cc: Ian Lance Taylor , Janboe Ye , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00374.txt.bz2 Hi, Frank >Those in turn >might be represented with almost the normal mf_xform_decls(), while >letting __builtin_alloca() remain. How can we just remain __builtin_alloca() only for variable-length array? Mudflap changes expand_builtin_alloca function. I think it is enough for apply mudflap in Linux Kernel. Janboe Ye 2009/7/16 Frank Ch. Eigler : > >> 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. =A0But 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: > > =A0__builtin_alloca(N) =A0--> =A0GIMPLE_TRY_FINALLY( try { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ptr =3D __= builtin_alloca(N) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__mf_regis= ter(ptr ...) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ptr; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } finally (attached t= o the function scope) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__mf_unreg= ister(ptr ...) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > 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. =A0Those in turn > might be represented with almost the normal mf_xform_decls(), while > letting __builtin_alloca() remain. > > Either of these requires gcc changes though. > > >> [...] =A0Although, 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 >