From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755213AbdETXAp (ORCPT ); Sat, 20 May 2017 19:00:45 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:34449 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403AbdETXAn (ORCPT ); Sat, 20 May 2017 19:00:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> <20170519205354.caeyqri2k6gvso3w@treble> <8dbbb971-fc41-fba2-f356-931a7eabe6ef@zytor.com> <20170519212913.otir6mlujoxoy3ha@treble> <20170519213556.pv5kxocfprfkloay@treble> From: Linus Torvalds Date: Sat, 20 May 2017 16:00:41 -0700 X-Google-Sender-Auth: 8wh4t2JMCjttITWHIwWwvjkOXTE Message-ID: Subject: Re: [PATCH 7/7] DWARF: add the config option To: Andy Lutomirski Cc: Josh Poimboeuf , "H. J. Lu" , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , Jiri Slaby , Andrew Morton , live-patching@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , Jiri Kosina Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 20, 2017 at 2:56 PM, Andy Lutomirski wrote: > On Sat, May 20, 2017 at 1:16 PM, Linus Torvalds > wrote: >> >> The amount of unreadable crap and bugs it requires is not worth the >> pain. Not for *any* amount of gain, and the gain here is basically >> zero. > > But what if objtool autogenerated the annotations, perhaps with a tiny > bit of help telling it "hardware frame goes here" or "pt_regs goes > here"? You snipped the next part of my email, where I said: > The *only* acceptable model is automated tools (ie objtool). Don't > even bother to try to go any other way. Because I will not accept that > shit. so yes, objtool parsing things on its own is acceptable (and it had better not need any help - it already checks frame pointer data). The CFI annotations needed in asm are horrendous. We used to have them, and we didn't have even _remotely_ complete annotations and despite that they were (a) wrong (b) incomplete (c) made the asm impossible to read and even worse to modify. hjl already posted an example of the kinds of horrors glibc does to do things "right". And those rabbit ears around "right" are there for a reason. There's no way that is ever right - even if it gets the right results, it's an unmaintainable piece of crap. So no, we're never ever adding that CFI garbage back into the kernel. A tool that can generate it is ok, but even then we should expect inevitable bugs and not trust the end result blindly. Because dwarf info is complex enough that other tools have gotten it wrong many many times. Just google for "gcc bugzilla cfi" or go to the gcc bugzilla and search for "DWARF" or whatever. It's not "oh, we once had a bug". It's constant. One of the reasons I like the idea of having objtool generate something *simpler* than dwarf is that it not only is much easier to parse, it has a much higher likelihood of not having some crazy bug. If objtool mainly looks at the actual instructions, and perhaps uses dwarf information as additional input and creates something much simpler than dwarf, it might have a chance in hell of occasionally even getting it right. Because dwarf information is really really complicated. It's complicated because it contains *way* more information than just how to find the next stack frame. I mean, it has basically a RPN interpreter built in, and that's the _simple_ part. Linus