From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754090AbdEIO6U (ORCPT ); Tue, 9 May 2017 10:58:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57084 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752702AbdEIO6S (ORCPT ); Tue, 9 May 2017 10:58:18 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 080345BECB Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 080345BECB Date: Tue, 9 May 2017 09:58:15 -0500 From: Josh Poimboeuf To: hpa@zytor.com Cc: 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 , hjl.tools@gmail.com Subject: Re: [PATCH 7/7] DWARF: add the config option Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <02DBEB97-7A38-468F-AFCC-0FB578079428@zytor.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 09 May 2017 14:58:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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