From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953AbdEJNJh (ORCPT ); Wed, 10 May 2017 09:09:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52080 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593AbdEJNJf (ORCPT ); Wed, 10 May 2017 09:09:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0F6B6804E9 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0F6B6804E9 Date: Wed, 10 May 2017 08:09:23 -0500 From: Josh Poimboeuf To: Jiri Slaby Cc: hpa@zytor.com, Andy Lutomirski , 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 Subject: Re: [PATCH 7/7] DWARF: add the config option Message-ID: <20170510130923.pt5kpqha7z3dj5uk@treble> 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> <43237c34-9945-096c-6ba2-cb2e6319985b@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <43237c34-9945-096c-6ba2-cb2e6319985b@suse.cz> 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.27]); Wed, 10 May 2017 13:09:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2017 at 10:15:09AM +0200, Jiri Slaby wrote: > > 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. I don't think so. DWARF CFI is optimized for size. My proposal is to take the same data (or some subset of it) and reformat it to optimize for simplicity. If, for some reason, we ended up needing *all* the original DWARF data, we could still have it in the simpler format. In that case it might end up being 8M instead of 2M :-) But I don't see that being possible. -- Josh