From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752529AbdEJIPQ (ORCPT ); Wed, 10 May 2017 04:15:16 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:33439 "EHLO mail-wr0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751858AbdEJIPM (ORCPT ); Wed, 10 May 2017 04:15:12 -0400 Subject: Re: [PATCH 7/7] DWARF: add the config option To: hpa@zytor.com, Josh Poimboeuf , Andy Lutomirski References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> <20170509013818.i2njk66mcgp4rtp7@treble> <20170509033831.6zoplbhnidbix5ua@treble> <02DBEB97-7A38-468F-AFCC-0FB578079428@zytor.com> Cc: Linus Torvalds , Andrew Morton , live-patching@vger.kernel.org, Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , Jiri Kosina , hjl.tools@gmail.com From: Jiri Slaby Message-ID: <43237c34-9945-096c-6ba2-cb2e6319985b@suse.cz> Date: Wed, 10 May 2017 10:15:09 +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: <02DBEB97-7A38-468F-AFCC-0FB578079428@zytor.com> 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, 12:00 PM, hpa@zytor.com wrote: > As far as I understand, the .eh_frame section is supposed to contain the subset of the DWARF bytecode needed to do a stack unwind when an exception is thrown, whereas the .debug* sections contain the full DWARF data a debugger might want. Thus .eh_frame is mapped into the runtime process while .debug* [usually?] is not. .debug* can easily be 10x larger than the executable text segments. As it currently stands, the (same) data is generated either to .eh_frame, or to .debug_frame. Depending if DWARF_UNWINDER is turned on, or off, respectively. vdso has the same data in both, always. > Assembly language routines become problematic no matter what you do unless you restrict the way the assembly can be written. Experience has shown us that hand-maintaining annotations in assembly code is doomed to failure, and in many cases it isn't even clear to even experienced programmers how to do it. Sure, manual annotations of assembly will be avoided as much as possible. We have to rely objtool to generate them in most cases. > [H.J.: is the .cfi_* operations set even documented anywhere in a way that non-compiler-writers can comprehend it?] Until now, I always looked into as manual: $ pinfo --node='CFI directives' as > I'm, ahem, highly skeptical to creating our own unwinding data format unless there is *documented, supported, and tested* way to force the compiler to *automatically* fall back to frame pointers any time there may be complexity involved, I second this. Inventing a new format like this mostly ends up with using the standard one after several iterations. One cannot think of all the consequences and needs while proposing a new one. The memory footprint is ~2M for average vmlinux. And people who need to access: * either need it frequently -- those do not need performance (LOCKDEP, KASAN, or other debug builds) * or are in the middle of WARNING, BUG, crash, panic or such and this is not that often... And we would need *both*. The limited proprietary one in some sort of .kernel_eh_frame, and DWARF cfis in .debug_frame for tools like crash, gdb and so on. And yes, the DWARF unwinder falls back to FP if they are available (see function dw_fp_fallback). thanks, -- js suse labs