Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754199AbdCHS5d (ORCPT ); Wed, 8 Mar 2017 13:57:33 -0500 Received: from mail-it0-f45.google.com ([209.85.214.45]:36237 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753795AbdCHS5a (ORCPT ); Wed, 8 Mar 2017 13:57:30 -0500 MIME-Version: 1.0 In-Reply-To: <20170308173703.2h57rsltma3smbcm@treble> References: <20170222231808.hmr6ulbvfnrg2at7@treble> <20170223201039.GB5177@amd> <20170225050439.7dplheb6nyne4nkm@treble> <20170302234514.3qcqdozibcltkdai@treble> <20170306163807.GA20689@amd> <20170307173821.yknj5htr7plgdwxv@treble> <20170307182855.262ezbon2pm67qfd@treble> <20170308173703.2h57rsltma3smbcm@treble> From: Linus Torvalds Date: Wed, 8 Mar 2017 10:25:01 -0800 X-Google-Sender-Auth: Lk35JwJUY8p9XJTJPrs1eYwoYFs Message-ID: Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null) To: Josh Poimboeuf Cc: Andy Lutomirski , Pavel Machek , kernel list , Ingo Molnar , Andrew Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , Peter Anvin , Peter Zijlstra , Thomas Gleixner 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: 3053 Lines: 75 On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf wrote: > > It does seem to make it bigger. With Pavel's config on gcc 6, if I add > -maccumulate-outgoing-args: > > That's 3.8% more text on x86-32. That's even more than I expected. I would have expected the -mregparm=3 to catch so much of our stack setup that it wouldn't be all that noticeable. But apparently we just have a ton of functions with more than 3 arguments. > (FWIW, on x86-64, the size difference is negligible.) Yeah, I seriously hope we've actively tried to avoid the more than six argument calling conventions. The mm code had some that grew over time, but most of that got converted to passing a pointer to a descriptor structure instead (ie "struct vm_fault" etc models). > As it turns out, when optimizing for size, gcc seems to ignore > -maccumulate-outgoing-args completely. So I guess we would have to live > with both cases anyway. Which means I'll need to make the unwinder > smart enough to deal with it. > > But that brings up another question. If -maccumulate-outgoing-args is > ignored with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, wouldn't using that option > break the things which require -maccumulate-outgoing-args? > > So, looking deeper at the various reasons this flag is enabled, they > seem to be mostly obsolete. Good. > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug > where the stack gets aligned before the mcount call. This issue > should be mostly obsolete as most modern compilers now have -mfentry. > We could make it dependent on CC_USING_FENTRY. Yeah. At some point we might even upgrade the compiler requirements to no longer accept the mcount model. I think the fentry model is gcc-4.6.0 and up. Currently I guess we support gcc-3.2+, which is fairly ridiculous considering that 4.6.0 is from March, 2011. So it's over five years ago already. gcc-3.2.0 is from 2002, I think. At some point you just have to say "caring about a 15 year old compiler is ridiculous" The main reason we have fairly aggressively supported old compilers tends to be some odder architectures that don't have good support, so people use various random "this works for me" versions. We could easily make the gcc version checks much more strict on x86, I suspect. > - CONFIG_JUMP_LABEL sets it on x86-32 because of a bug in gcc <= 4.5.1 > which has since been fixed with > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226. We could probably > make it gcc-version-dependent. Looks like we could just use the FENTRY test, since that's more recent. > - x86-64 sets it to apparently make the no-longer-in-tree DWARF unwinder > happy with older versions of gcc. Ok. Since it's not as big of a deal on x86-64 I guess we don't care, but on the other hand it would probably then be better to aim to switch away from it entirely and just put that whole sorry thing behind us. > So it looks like -maccumulate-outgoing-args isn't actually needed in > most cases. That would be lovely indeed. Linus