From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752007AbdEJIcP (ORCPT ); Wed, 10 May 2017 04:32:15 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34188 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751081AbdEJIcJ (ORCPT ); Wed, 10 May 2017 04:32:09 -0400 Subject: Re: [PATCH 7/7] DWARF: add the config option To: Josh Poimboeuf , Jiri Kosina References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> <20170509192253.5lsb3yg2nwl2nrcw@treble> Cc: Linus Torvalds , Andrew Morton , live-patching@vger.kernel.org, Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Andy Lutomirski From: Jiri Slaby Message-ID: <18abff55-25d0-e783-8e1f-97bef42da1e3@suse.cz> Date: Wed, 10 May 2017 10:32:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170509192253.5lsb3yg2nwl2nrcw@treble> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/09/2017, 09:22 PM, Josh Poimboeuf wrote: > On Tue, May 09, 2017 at 08:47:50PM +0200, Jiri Kosina wrote: >> On Sun, 7 May 2017, Josh Poimboeuf wrote: >> >>> DWARF is great for debuggers. It helps you find all the registers on >>> the stack, so you can see function arguments and local variables. All >>> expressed in a nice compact format. >>> >>> But that's overkill for unwinders. We don't need all those registers, >>> and the state machine is too complicated. >> >> OTOH if we make the failures in processing of those "auxiliary" >> information non-fatal (in a sense that it neither causes kernel bug nor >> does it actually corrupt the unwinding process, but the only effect is >> losing "optional" information), having this data available doesn't hurt. > > But it does hurt, in the sense that the complicated format of DWARF CFI > means the unwinder has to jump through a lot more hoops to read it. Why that matters, actually? Unwinder is nothing to be performance oriented. And if somebody is doing a lot of unwinding during runtime, they can switch to in-this-case-faster FP unwinder. > And if we wanted it to be reasonably reliable, we'd also need to fix up > the DWARF data somehow before converting it, presumably with objtool. We have to do this anyway. Be it the DWARF info or whatever we end up with. >>> Unwinders basically only need to know one thing: given an instruction >>> address and a stack pointer, where is the caller's stack frame? >> >> Again, DWARF should be able to give us all of this (including the >> FP-fallback etc). It feels a bit silly to purposedly ignore it and >> reinvent parts of it again, instead of fixing (read: "asking toolchain >> guys to fix") And we can just do, if a totally broken compiler emerges: #if defined(CONFIG_DWARF_UNWINDER) && GCC_VERSION == 59000 #error Sorry, choose a different compiler or disable DWARF unwinder #endif We haven't to do this during the past decade and I am sceptic if we would have to do it in the next one. >> the cases where we actually are not getting the proper data >> in DWARF. That's a win-win at the end of the day. > > Most of the kernel DWARF issues I've seen aren't caused by toolchain > bugs. They're caused by the kernel's quirks: asm, inline asm, special > sections. Right. > And anyway, fixing the correctness of the DWARF data is only half the > problem IMO. The other half of the problem is unwinder complexity. Complex, but generic and working. IMO, it would be rather though to come up with some tool working on different compilers or even different versions of gcc. I mean some tool to convert the DWARF data to something proprietary. The conversion would be as complex as is the unwinder plus conversion to the proprietary format and its dump into ELF. We would still rely on a (now out-of-kernel-runtime-code) complex monolith to do it right. thanks, -- js suse labs