Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752093AbdGLXWo (ORCPT ); Wed, 12 Jul 2017 19:22:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:43764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751046AbdGLXWn (ORCPT ); Wed, 12 Jul 2017 19:22:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACCC622C9C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: <87wp7dmgoo.fsf@firstfloor.org> References: <87wp7dmgoo.fsf@firstfloor.org> From: Andy Lutomirski Date: Wed, 12 Jul 2017 16:22:21 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf) To: Andi Kleen Cc: Josh Poimboeuf , X86 ML , "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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1295 Lines: 26 On Wed, Jul 12, 2017 at 3:30 PM, Andi Kleen wrote: > Josh Poimboeuf writes: >> >> The ORC data format does have a few downsides compared to DWARF. The >> ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables. >> > Can we have an option to just use dwarf instead? For people > who don't want to waste a MB+ to solve a problem that doesn't > exist (as proven by many years of opensuse kernel experience) > > As far as I can tell this whole thing has only downsides compared > to the dwarf unwinder that was earlier proposed. I don't see > a single advantage. > If someone wanted to write an in-kernel DWARF parser that hooked into the same machinery that Josh is using and comes with a complete formal verification package, I might not object, with the caveat that it's likely to be *much* slower than ORC. By complete formal verification, I mean that a user tool running the exact same code, compiled with strong sanitization, should decode the tables for every single kernel IP and confirm that (a) the output is sane, (b) the output matches what objtool says it should do and (c) doesn't crash. I'm not sure I see the point, though. I also think that Linus would object, since I asked him quite recently and he said he'd object.