Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933705AbbFJNwP (ORCPT ); Wed, 10 Jun 2015 09:52:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42391 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933490AbbFJNwG (ORCPT ); Wed, 10 Jun 2015 09:52:06 -0400 Date: Wed, 10 Jun 2015 08:52:03 -0500 From: Josh Poimboeuf To: Andi Kleen Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , Andy Lutomirski , Borislav Petkov , Linus Torvalds , x86@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 00/10] x86/asm: Compile-time asm code validation Message-ID: <20150610135203.GA19509@treble.redhat.com> References: <20150610130814.GN19417@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150610130814.GN19417@two.firstfloor.org> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1609 Lines: 41 On Wed, Jun 10, 2015 at 03:08:14PM +0200, Andi Kleen wrote: > > > 2. Each callable function must never leave its own bounds (i.e. with a > > jump to outside the function) except when returning. > > That prevents a lot of optimizations with out of line code. In most cases there are ways to keep the optimizations. For example: - grow the function bounds to keep the jump internal - duplicate the destination code inside the function - convert the jump to a call Also note that these rules only affect _callable_ functions, so the entry code and other non-function asm code can still be a pile of spaghetti (though I think Andy is working on improving that). > In fact even gcc with the right options can generate code that violates > this. Standard Linux constructions, such as exception handling, > also violate this. > > If your tool needs that your tool is broken. This tool only validates asm code, so I don't see how whatever gcc does is relevant. > BTW any other frame pointer requirement should be also optional, > as it slows down a number of CPUs, such as Atoms. Yes. This patch set is a first step towards being able to disable frame pointers. Once all callable functions are reasonably structured, we can start generating and validating DWARF CFI data. Then we can make a reliable DWARF unwinder and get rid of frame pointers. -- Josh -- 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/