From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754593AbdEIQqL (ORCPT ); Tue, 9 May 2017 12:46:11 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:35944 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751947AbdEIQqJ (ORCPT ); Tue, 9 May 2017 12:46:09 -0400 MIME-Version: 1.0 In-Reply-To: <20170509145815.pb2pyo3r6sj5nehe@treble> References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> <20170509013818.i2njk66mcgp4rtp7@treble> <20170509033831.6zoplbhnidbix5ua@treble> <02DBEB97-7A38-468F-AFCC-0FB578079428@zytor.com> <20170509145815.pb2pyo3r6sj5nehe@treble> From: "H.J. Lu" Date: Tue, 9 May 2017 09:46:08 -0700 Message-ID: Subject: Re: [PATCH 7/7] DWARF: add the config option To: Josh Poimboeuf Cc: "H. Peter Anvin" , Andy Lutomirski , Linus Torvalds , Jiri Slaby , Andrew Morton , live-patching@vger.kernel.org, Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , Jiri Kosina Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 9, 2017 at 7:58 AM, Josh Poimboeuf wrote: > On Tue, May 09, 2017 at 03:00:45AM -0700, hpa@zytor.com wrote: >> I'm, ahem, highly skeptical to creating our own unwinding data format >> unless there is *documented, supported, and tested* way to force the >> compiler to *automatically* fall back to frame pointers any time there >> may be complexity involved, which at a very minimum includes any kind >> of data-dependent manipulation of the stack pointer. > > That would be nice. But isn't falling back to a frame pointer (or > another callee-saved reg or a stack location) already needed in such > cases? Otherwise how could DWARF unwinding work? > >> Otherwise you will have to fail the kernel build when your static tool >> runs into instruction sequences it can't deal with, but the compiler >> may generate them - boom. > > Failing the build is harsh, we could just warn about it and skip the > data for the affected function(s). > > BTW, there is another option. Instead of generating the data from > scratch, we could just convert gcc's DWARF CFI to the format we need. > > However that wouldn't solve the problems we have with the holes and > inaccuracies in DWARF from our hand-annotated asm, inline asm, and > special sections (extable, alternatives, etc). We'd still have to rely > on objtool for that, so we'd still be in the same boat of needing > objtool to be able to follow gcc code paths. CFI directives are documented in GNU assembler manual. They store unwind info in .eh_frame section. They work well with assembly codes in glibc. But I don't know how well they work with kernel unwind. > So yes, it sucks that objtool needs to work for unwinding to work. But > if we want decent DWARF-esque unwinding, I don't see any way around > that due to the low-level nature of the kernel. > >> Worse, your tool will not even recognize the problem and you're in a >> worse place than when you started. > > We could have a runtime NMI-based stack checker which ensures it can > always unwind to the bottom of the stack. Over time this would > hopefully provide full validation of the unwinder data and > functionality. > > -- > Josh -- H.J.