From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105502 invoked by alias); 3 Jun 2015 08:53:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105469 invoked by uid 89); 3 Jun 2015 08:53:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 03 Jun 2015 08:53:09 +0000 Received: by obbea3 with SMTP id ea3so2572533obb.0 for ; Wed, 03 Jun 2015 01:53:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.240.135 with SMTP id wa7mr20845648obc.63.1433321587239; Wed, 03 Jun 2015 01:53:07 -0700 (PDT) Received: by 10.202.210.84 with HTTP; Wed, 3 Jun 2015 01:53:07 -0700 (PDT) In-Reply-To: <5565E07E.2070703@redhat.com> References: <20150318115630.GA64546@msticlxl57.ims.intel.com> <20150331094702.GC52842@msticlxl57.ims.intel.com> <5521E515.2030802@codesourcery.com> <20150406151742.GA43634@msticlxl57.ims.intel.com> <5522A636.9030000@redhat.com> <20150526091327.GI47912@msticlxl57.ims.intel.com> <5565E07E.2070703@redhat.com> Date: Wed, 03 Jun 2015 09:04:00 -0000 Message-ID: Subject: Re: [PATCH, libmpx, i386, PR driver/65444] Pass '-z bndplt' when building dynamic objects with MPX From: Ilya Enkovich To: Jeff Law Cc: Sandra Loosemore , Joseph Myers , Richard Biener , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00283.txt.bz2 2015-05-27 18:19 GMT+03:00 Jeff Law : > On 05/26/2015 03:13 AM, Ilya Enkovich wrote: >> >> On 06 Apr 09:28, Jeff Law wrote: >>> >>> On 04/06/2015 09:17 AM, Ilya Enkovich wrote: >>>>> >>>>> >>>>> To tell the truth, I can't figure out what this means from a user >>>>> perspective. How does a user know whether the linker option is >>>>> being ignored, or if they have a new enough linker? If the linker >>>>> available at configuration time doesn't support the option, does >>>>> that mean the option will never be passed and users will never know >>>>> that there are gaping holes in the pointer bounds checking? >>>>> >>>>> My suggestion would be to pass the option unconditionally and make >>>>> the documentation say something like >>>> >>>> >>>> This option was rejected. >>> >>> Right. There really isn't a good option here because we don't have >>> the infrastructure to query the linker's capabilities at link time. >>> >>> Though I do wonder if we could issue a warning in the case where the >>> configure test indicated -z bndplt was not supported. >>> >>> It'd obviously mean a link warning every time an end user tried to >>> use that toolchain to create a DSO or executable with MPX >>> protection. But that may be better than silently leaving some code >>> unprotected. >>> >>> >>> Jeff >>> >> >> Hi, >> >> Here is a patch to add a note in case we build dynamic MPX codes and don't >> pass '-z bndplt'. Does it look OK? >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-05-26 Ilya Enkovich >> >> * config/i386/linux-common.h (MPX_SPEC): Add link >> warning. >> >> libmpx/ >> >> 2015-05-26 Ilya Enkovich >> >> * configure.ac: Add link_mpx_warning. >> * libmpx.spec.in: Likewise. >> * configure: Regenerate. > > Is there a way to do this outside of the specs mechanism? If done in the > specs, are these warnings translated for locales? Specs seem to be the least intrusive way to emit some target specific message in the driver. I didn't want to add some new features into the driver just for this single warning. Spec files are not scanned by translator. I tried to split this spec into two parts to move message into a header file but with no success. Any ideas how it can be done? Ilya > > Jeff >