Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752209AbdGLWc3 (ORCPT ); Wed, 12 Jul 2017 18:32:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57334 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbdGLWc1 (ORCPT ); Wed, 12 Jul 2017 18:32:27 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 475067F6A6 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 475067F6A6 Date: Wed, 12 Jul 2017 17:32:25 -0500 From: Josh Poimboeuf To: Andres Freund Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf) Message-ID: <20170712223225.zkq7tdb7pzgb3wy7@treble> References: <20170712214920.5droainfqjmq7sgu@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170712214920.5droainfqjmq7sgu@alap3.anarazel.de> 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.25]); Wed, 12 Jul 2017 22:32:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1322 Lines: 31 On Wed, Jul 12, 2017 at 02:49:20PM -0700, Andres Freund wrote: > Hi, > > On 2017-07-11 10:33:37 -0500, Josh Poimboeuf wrote: > > The simpler debuginfo format also enables the unwinder to be much faster > > than DWARF, which is important for perf and lockdep. > > Is this going to be usable for userland call-graphs as well? If one > converts dwarf to that, I mean? Because right now with perf dwarf is > often the only thing that works properly through libc, as libc isn't > compiled with fps and has hardcoded asm not preserving fp. lbr isn't > available for many events, and often not at all available in VMs etc. Just to clarify, these patches are completely separate from DWARF and shouldn't break any existing DWARF-based functionality for user space tooling. So perf can still use DWARF for user space binaries just fine. (Also, tools which rely on CONFIG_DEBUG_INFO for kernel debugging, like gdb and crash, will continue to work.) If you want perf to be able to use ORC instead of DWARF for user space binaries, that's not currently possible, though I don't see any technical blockers for doing so. Perf would need to be taught to read ORC data. And I think it should be possible to convert DWARF to ORC, assuming the DWARF data is trusted. We could probably add an objtool subcommand for that. -- Josh