From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10531 invoked by alias); 11 Nov 2014 18:04:20 -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 10494 invoked by uid 89); 11 Nov 2014 18:04:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Nov 2014 18:04:18 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XoFna-0004su-H0 from joseph_myers@mentor.com ; Tue, 11 Nov 2014 10:04:14 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.181.6; Tue, 11 Nov 2014 18:04:13 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1XoFnY-0001CP-A8; Tue, 11 Nov 2014 18:04:12 +0000 Date: Tue, 11 Nov 2014 18:09:00 -0000 From: Joseph Myers To: Ilya Enkovich CC: Subject: Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library In-Reply-To: <20141111153449.GB52080@msticlxl57.ims.intel.com> Message-ID: References: <20141111153449.GB52080@msticlxl57.ims.intel.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-11/txt/msg01051.txt.bz2 On Tue, 11 Nov 2014, Ilya Enkovich wrote: > Hi, > > This patch integrates MPX runtime library into GCC source tree. MPX > runtime is responsible for initialization of MPX feature in HW, signal > handling, reporting etc. Library is linked to codes compiled with > -mmpx. > > Bootstrap is OK for x86_64-unknown-linux-gnu. OK for trunk? Please use symbol versioning to control the set of exports for the library; only symbols explicitly listed to be exported at a given symbol version should be exported. If the library is intended to be used implicitly by compiler-generated code rather than directly by users, all exported symbols should be in the implementation namespace - only symbols intended to be called by users should not start with "__". In any case, symbols not intended to be exported should be in the implementation namespace, or static, to avoid namespace issues for static linking. The code contains unchecked malloc calls. You always need to allow for errors from library functions. The code contains unchecked sprintf to static buffers using values from the environment. Use snprintf. The code contains calls to getenv to choose files to open. You need to use __secure_getenv / secure_getenv when available (probably for all getenv calls, unless you have a clear reason certain calls are safe even for setuid programs). You have lots of static writable variables. Are you sure all those variables are handled in a thread-safe way (e.g. only modified before any threads start)? -- Joseph S. Myers joseph@codesourcery.com