Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932324AbbGTH4T (ORCPT ); Mon, 20 Jul 2015 03:56:19 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:36304 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932294AbbGTH4R (ORCPT ); Mon, 20 Jul 2015 03:56:17 -0400 Date: Mon, 20 Jul 2015 09:56:11 +0200 From: Ingo Molnar To: Josh Poimboeuf Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Andi Kleen , Pedro Alves , X86 ML , live-patching@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S Message-ID: <20150720075611.GA11874@gmail.com> References: <2ea0f0602978178eafd012e52b8bdb83cfb159d5.1437150175.git.jpoimboe@redhat.com> <20150717194307.GA26757@gmail.com> <20150717203746.GB12761@treble.redhat.com> <20150718025116.GB13059@gmail.com> <20150718035623.GA22664@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150718035623.GA22664@treble.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2332 Lines: 54 * Josh Poimboeuf wrote: > On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote: > > Note what the names _don't_ contain: that we generate debug info! That fact is not > > present in the naming, and that's very much intentional, because the precise form > > of debug info is conditional: > > > > - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame > > > > - if (later on) we do CFI annotations we don't push/pop a stack frame but emit > > CFI debuginfo > > According to current plan, the macro won't add CFI annotations. That will be > done instead by a separate tool. So the macro really is frame pointer specific. Still the same argument applies: it's a debug info detail we should hide as much as sensibly possible. In the CONFIG_FRAME_POINTERS=y case it will be code, in the future !CONFIG_FRAME_POINTERS case it will be nothing. > > In that sense 'FRAME' should never be in these names I think, nor 'PROC' > > (which is not symmetric). > > > > Plus all 3 variants I suggested are very easy to remember, why I'd always have > > to look up any non-symmetric macro name called 'PROC'... > > The reason I suggested to put FRAME in the macro name is to try to prevent it > from being accidentally used for leaf functions, where it isn't needed. Well, we could use LEAF_FUNCTION to mark that fact. Wether a function written in assembly is a leaf function or not is a higher level (and thus more valuable) piece of information whether we generate frame pointer debuginfo or not. > Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do anything to > distinguish them from the already ubiquitous ENTRY and ENDPROC. So as a kernel > developer it seems confusing to me, e.g. how do I remember when to use > FUNCTION_ENTRY vs ENTRY? 'ENDPROC' is really leftover from older debuginfo cruft, it's not a valuable construct IMHO, even if it's (sadly) ubiquitious. We want to create new, clean, as minimal as possible and as clearly named as possible debuginfo constructs from first principles. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/