From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19336 invoked by alias); 12 Nov 2014 21:40:50 -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 19323 invoked by uid 89); 12 Nov 2014 21:40:50 -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; Wed, 12 Nov 2014 21:40:49 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Xofee-0001YP-8k from joseph_myers@mentor.com ; Wed, 12 Nov 2014 13:40:44 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Wed, 12 Nov 2014 21:40:42 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1Xofec-0001oA-9S; Wed, 12 Nov 2014 21:40:42 +0000 Date: Wed, 12 Nov 2014 21:41:00 -0000 From: Joseph Myers To: Ilya Enkovich CC: Andi Kleen , Subject: Re: [PATCH, MPX runtime 1/2] Integrate MPX runtime library In-Reply-To: <20141112160432.GA5697@msticlxl57.ims.intel.com> Message-ID: References: <20141111153449.GB52080@msticlxl57.ims.intel.com> <87r3x9a7yt.fsf@tassilo.jf.intel.com> <20141112160432.GA5697@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/msg01333.txt.bz2 On Wed, 12 Nov 2014, Ilya Enkovich wrote: > MPX runtime needs to be linked with programs using MPX because it > initializes hardware. Without it all MPX instructions are just NOPs. > Thus it's not an extra functionality, but is for basic MPX > functionality. So what if you just have the constructor that initializes the hardware - could everything else (handling environment variables, printing more detailed diagnostics, etc.) be separate? How much is basic MPX functionality, how much is extra? Basic functionality should arguably be like libgcc in namespace terms (so not calling any libc functions outside of ISO C90 namespace, using reserved-namespace versions such as __write instead if necessary and if such versions are available); extra functionality need not be so restricted. > I also fixed other issues you mentioned in your previous comments. > Below is a new version. Does it look better? I don't see anything obvious to do symbol versioning. If this isn't providing interfaces for the user program or compiler-generated code to call, then the symbol versioning could hide all symbols (so there are no exported symbols at all and the library operates purely through its initialization constructor). Or build with -fvisibility=hidden to hide the symbols that way. Either way, the dynamic symbol table of the shared library would end up with just undefined symbols, nothing exported by the library. The issue with signal handlers calling inappropriate functions still applies - you're calling vfprintf from a signal handler. Using pthread_mutex_lock around it doesn't help at all; vfprintf can call malloc, and the signal may have interrupted malloc, for example. You really can't use stdio at all inside signal handlers - if you want to do I/O in them, you have to use write (). (There's an argument that dprintf or an snprintf/write combination ought to be AS-safe, but currently they aren't; see ; snprintf is probably safe than dprintf in practice.) I mentioned the question of static writable variables. If those variables are only ever modified at startup, before any threads have been created, could you add comments to that effect (and otherwise ensure comments on the variables explain how you ensure they are accessed in a thread-safe way)? -- Joseph S. Myers joseph@codesourcery.com