From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127910 invoked by alias); 8 Dec 2018 12:05:06 -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 127877 invoked by uid 89); 8 Dec 2018 12:05:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=argue, appealed, FreeRTOS, H*f:sk:54470cf X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Dec 2018 12:05:02 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id wB813Tii019838; Fri, 7 Dec 2018 19:03:30 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id wB7NZRRG014776; Fri, 7 Dec 2018 17:35:27 -0600 Date: Sat, 08 Dec 2018 12:05:00 -0000 From: Segher Boessenkool To: Niklas DAHLQUIST Cc: Jeff Law , Torbjorn SVENSSON , "gcc-patches@gcc.gnu.org" , "Joey.Ye@arm.com" , Samuel HULTGREN , Christophe LYON , Christophe MONAT Subject: Re: [PATCH] Added information about inline assembler in stack calculations (.su files) Message-ID: <20181207233525.GF3803@gate.crashing.org> References: <7f229423-5edb-88e8-a5c2-7c9660339255@st.com> <54470cff-6d6c-f3b4-7958-420d1e512200@redhat.com> <4299eced-a99a-7584-4253-9648dd99e67e@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4299eced-a99a-7584-4253-9648dd99e67e@st.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00511.txt.bz2 Hi! On Fri, Dec 07, 2018 at 07:51:35AM +0000, Niklas DAHLQUIST wrote: > On 12/1/18 1:15 AM, Jeff Law wrote: > > One could argue that allocating stack space inside an ASM is a really > > bad idea. Consider things like dwarf debugging and unwind tables. If > > you're allocating stack inside an ASM that stuff is going to be totally > > wrong. > > > > So I think my question before moving forward with something like this is > > whether or not it makes sense at all to bother dumping data for a > > scenario that we'd probably suggest developers avoid to begin with. > > The purpose of the patch is to notify when the reported stack usage might be > incorrect. Even if it's bad practice to alter stack in asm, there are > use cases > in the embedded world that makes sense. A notable common use case is > FreeRTOS > task switch using ARM "naked" attribute and inline asm, which reports "0 > static", > which gives a faulty stack usage. We have considered the other option to > report a warning for these cases, but that alternative hasn't appealed > to us. Would that work well? Only warn for naked functions? It would work better for all users that do *not* mess with the stack in their asm ;-) Segher