From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942456AbcJSPuJ (ORCPT ); Wed, 19 Oct 2016 11:50:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:40175 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756909AbcJSOXw (ORCPT ); Wed, 19 Oct 2016 10:23:52 -0400 Date: Wed, 19 Oct 2016 13:11:31 +0200 (CEST) From: Richard Biener To: Peter Zijlstra cc: "Luis R. Rodriguez" , Vegard Nossum , Jiri Slaby , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Linus Torvalds , stable@vger.kernel.org, Ming Lei , Steven Rostedt , "H. Peter Anvin" , Josh Poimboeuf , Cesar Eduardo Barros , Michael Matz , David Miller , Guenter Roeck , Fengguang Wu , Borislav Petkov , Boris Ostrovsky , Juergen Gross , Kees Cook , Arnaldo Carvalho de Melo , Ingo Molnar , Thomas Gleixner Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts In-Reply-To: <20161019102555.GJ3102@twins.programming.kicks-ass.net> Message-ID: References: <20161017083315.GA29322@worktop.vlan200.pylonone.local> <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> <20161017090930.GT3142@twins.programming.kicks-ass.net> <55e00c01-2da8-8d06-1d05-9ebf775736ec@oracle.com> <20161017114517.GQ3117@twins.programming.kicks-ass.net> <55b3cbe0-f8fc-6505-411d-5f050d3414cc@oracle.com> <20161018211803.GV8651@wotan.suse.de> <20161019091347.GE3102@twins.programming.kicks-ass.net> <20161019102555.GJ3102@twins.programming.kicks-ass.net> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Oct 2016, Peter Zijlstra wrote: > On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote: > > On Wed, 19 Oct 2016, Peter Zijlstra wrote: > > > > This is also an entirely different class of optimizations than the whole > > > pointer arithmetic is only valid inside an object thing. > > > > Yes, it is not related to that. I've opened > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 to track an > > inconsistency in that new optimization. > > > > > The kernel very much relies on unbounded pointer arithmetic, including > > > overflow. Sure, C language says its UB, but we know our memory layout, > > > and it would be very helpful if we could define it. > > > > It's well-defined and correctly handled if you do the arithmetic > > in uintptr_t. No need for knobs. > > So why not extend that to the pointers themselves and be done with it? > > In any case, so you're saying our: > > #define RELOC_HIDE(ptr, off) \ > ({ \ > unsigned long __ptr; \ > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ > (typeof(ptr)) (__ptr + (off)); \ > }) > > could be written like: > > #define RELOC_HIDE(ptr, off) \ > ({ \ > uintptr_t __ptr = (ptr); \ > (typeof(ptr)) (__ptr + (off)); \ > }) > > Without laundering it through inline asm? I think so. > Is there any advantage to doing so? asms always introduce issues with optimization passes that do not bother to handle it (and give up). And then there is register allocation - not sure how it is affected by the asm. Generally I'd say if you can do it w/o asm then better.. Note that old GCC may have had bugs that made the uintptr_t variant w/o the asm not work. > But this still means we need to be aware of this and use these macros to > launder our pointers. Yes, if you base 'ptr' on the address of a declaration at least. > Which gets us back to the issue that started this whole thread. We have > code that now gets miscompiled, silently. > > That is a bad situation. So we need to either avoid the miscompilation, > or make it verbose. GCC 7 is still not released and I think we should try not to break things without a good reason. > > > Can't we get a knob extending -fno-strict-aliasing to define pointer > > > arithmetic outside of objects and overflow? I mean, we already use that, > > > we also use -fno-strict-overflow and a whole bunch of others. > > > > > > At the very least, it would be nice to get a -W flag for when this alias > > > analysis stuff kills something so we can at least know when GCC goes and > > > defeats us. > > > > What kind of warning do you envision? > > > > "warning: optimized address comparison to always true/false" > > > > ? That would trigger all over the place. > > That is indeed what I was thinking of. And I have no idea how often that > would trigger on the kernel. > > I'm thinking that if this WARN isn't subject to false > positives we could live with that. Its the false positives that render > other warnings useless (too much noise on perfectly fine code etc..). > > /me ponders.. > > So there might be a problem if this triggers in generic code due to > conditions at its use site. There we would not want to, nor could, fix > the generic code because in generic the thing would not be optimized. So > maybe we'd need an annotation still. For C++ these kind of warnings trigger whenever abstraction penalty is removed. Like the typical template foo () { if (i) { } } triggering for a hypothetical -Wdead-code for i == 0. The kernel is known for its "C" abstraction stuff and I can believe that such -W flag would trigger for cases where abstraction is removed. Richard.