From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54236 invoked by alias); 31 May 2019 00:08:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 54228 invoked by uid 89); 31 May 2019 00:08:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 00:08:28 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EBB9083F45; Fri, 31 May 2019 00:08:26 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-56.rdu2.redhat.com [10.10.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id E414E608CA; Fri, 31 May 2019 00:08:25 +0000 (UTC) Subject: Re: [PATCH] warn on returning alloca and VLA (PR 71924, 90549) To: Jason Merrill Cc: Martin Sebor , gcc-patches References: <7dc3d2b2-7bd4-b82f-bc48-9e5878e27475@redhat.com> <0a1e0b3c-df54-6562-adf9-6facbc6dbd9f@gmail.com> <244d2a97-a753-4296-df9c-f53feaadd70d@redhat.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <6cebe9c6-3b0a-f2b4-85e0-45611e8c6777@redhat.com> Date: Fri, 31 May 2019 00:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg02073.txt.bz2 On 5/30/19 11:23 AM, Jason Merrill wrote: > On Thu, May 30, 2019 at 12:16 PM Jeff Law wrote: >> >> On 5/30/19 9:34 AM, Martin Sebor wrote: >> >>>>> If the alias oracle can be used to give the same results without >>>>> excessive false positives then I think it would be fine to make >>>>> use of it. Is that something you consider a prerequisite for >>>>> this change or should I look into it as a followup? >>>> I think we should explore it a bit before making a final decision. It >>>> may guide us for other work in this space (like detecting escaping >>>> locals). I think a dirty prototype to see if it's even in the right >>>> ballpark would make sense. >>> >>> Okay, let me look into it. >> Sounds good. Again, go with a quick prototype to see if it's likely >> feasible. The tests you've added should dramatically help evaluating if >> the oracle is up to the task. >> >>> >>>>> FWIW, I'm working on enhancing this to detect returning freed >>>>> pointers (under a different option). That seems like a good >>>>> opportunity to also look into making use of the alias oracle. >>>> Yes. I think there's two interesting cases here to ponder. If we free >>>> a pointer that must point to a local, then we can warn & trap. If we >>>> free a pointer that may point to a local, then we can only warn (unless >>>> we can isolate the path). >>> >>> I wasn't actually thinking of freeing locals but it sounds like >>> a useful enhancement as well. Thanks for the suggestion! :) >>> >>> To be clear, what I'm working on is detecting: >>> >>> void* f (void *p) >>> { >>> free (p); // note: pointer was freed here >>> // ... >>> return p; // warning: returning a freed pointer >>> } >> Ah, we were talking about different things. Though what you're doing >> might be better modeled in a true global static analyzer as a >> use-after-free problem. My sense is that translation-unit local version >> of that problem really isn't that useful in practice. THough I guess >> there isn't anything bad with having a TU local version. >> >> >>> >>>>> Besides these enhancements, there's also a request to diagnose >>>>> dereferencing pointers to compound literals whose lifetime has >>>>> ended (PR 89990), or more generally, those to any such local >>>>> object. It's about preventing essentially the same problem >>>>> (accessing bad data or corrupting others) but it seems that >>>>> both the analysis and the handling will be sufficiently >>>>> different to consider implementing it somewhere else. What >>>>> are your thoughts on that? >>>> I think the tough problem here is we lose binding scopes as we lower >>>> into gimple, so solving it in the general case may be tough. We've >>>> started adding some clobbers into the IL to denote object death points, >>>> but I'm not sure if they're sufficient to implement this kind of warning. >>> >>> I was afraid that might be a problem. >> Way back in the early days of tree-ssa we kept the binding scopes. But >> that proved problematical in various ways. Mostly they just got in the >> way of analysis an optimization and we spent far too much time in the >> optimizers working around them or removing those which were empty. >> >> They'd be helpful in this kind of analysis, stack slot sharing vs the >> inliner and a couple other problems. I don't know if the pendulum has >> moved far enough to revisit :-) > > Why wouldn't clobbers be sufficient? I haven't looked into the clobbers in any detail. If we're aggressively emitting them at the end of object life, then they may be sufficient to start tackling these issues. jeff