From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942849AbcJSOkD (ORCPT ); Wed, 19 Oct 2016 10:40:03 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:35121 "EHLO mail-qk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932790AbcJSOkA (ORCPT ); Wed, 19 Oct 2016 10:40:00 -0400 Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts To: Peter Zijlstra , Vegard Nossum References: <20161016151616.31451-1-vegard.nossum@oracle.com> <20161016151616.31451-2-vegard.nossum@oracle.com> <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> Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Linus Torvalds , "Luis R . Rodriguez" , stable@vger.kernel.org, Ming Lei , Steven Rostedt From: Jiri Slaby Message-ID: <286773cc-54b3-4a4e-2891-befdb48ad3f8@suse.cz> Date: Wed, 19 Oct 2016 09:16:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161017114517.GQ3117@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/17/2016, 01:45 PM, Peter Zijlstra wrote: > And given GCC7 is still in development, this might be a good time to get > a knob added for our benefit. I tried and failed, see below. Citing from: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 (In reply to Jiri Slaby from comment #16) > (In reply to Jakub Jelinek from comment #15) > > lots of them that rely on pointer arithmetics being defined only within the > > same object. > > Sure, but the two pointers (taken implicitly of the arrays) are within the > same object. So I do not see, why it wouldn't work? I.e. where exactly this > breaks the C specs? No. In C extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; declares two external arrays, thus they are two independent objects. It is like if you have: int a[10]; int b[10]; in your program, although they might be allocated adjacent, such that int *p = &a[10]; int *q = &b[0]; memcmp (&p, &q, sizeof (p)) == 0; &b[0] - &a[0] is still UB. What you do with __start_*/__end_* symbols is nothing you can define in C, you need linker support or asm for that, and to use it without UB you also need to use an optimization barrier that has been suggested. ============================== > And given gcc 7 is to be released yet, can we have a switch to disable this > optimization? This is nothing new in GCC 7, you've most likely just been extremely lucky in the past that it happened to work as you expected. Other projects had to change similar UB code years ago. It isn't just a single optimization, but lots of them that rely on pointer arithmetics being defined only within the same object. -- js suse labs