From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752777AbdEHGPk (ORCPT ); Mon, 8 May 2017 02:15:40 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:33885 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751872AbdEHGPi (ORCPT ); Mon, 8 May 2017 02:15:38 -0400 Date: Mon, 8 May 2017 08:15:34 +0200 From: Ingo Molnar To: Andy Lutomirski Cc: Josh Poimboeuf , Linus Torvalds , Jiri Slaby , Andrew Morton , live-patching@vger.kernel.org, Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Andy Lutomirski , Jiri Kosina Subject: Re: [PATCH 7/7] DWARF: add the config option Message-ID: <20170508061534.4pil6hleyvkutl6e@gmail.com> References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski wrote: > I think that, if the code were sufficiently robust, it would be handy if the > unwinder displayed function arguments. DWARF can do that to a limited extent. > > That being said, having a simpler table format would probably cover most of the > use cases. I'd say that if objtool generates the kernel's debuginfo, it all becomes a kernel internal matter to a large degree: we can add function argument display support as well and see what effect it has on data structure size and complexity - it would certainly be a nice improvement in oops output to see function arguments. But it should all start from a minimum complexity step (which will be complex enough!) and the first step should be stack trace display, in a performance optimized data structure, to allow both kernel stack dumps and various tracing and other instrumentation facilities that make use of the kernel's dwarf-ish unwider as-is. The goal of this first step would be to allow x86 to drop generating the RBP frame pointer: - This shrinks kernel text and instruction count (by 1-2% IIRC), - speeds up certain code paths measurably, - plus it also allows larger functions to use one more general purpose register. ... so it's a good thing to have, if and only if the unwinder's fragility and complexity does not kill us. And much of that fragility comes from who generates the debuginfo ... Thanks, Ingo