From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16104 invoked by alias); 7 Feb 2018 10:32:46 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13677 invoked by uid 89); 7 Feb 2018 10:32:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*f:sk:1517957, H*i:sk:1517957, our, management X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 10:32:43 +0000 Received: from ip-122.net-89-2-94.rev.numericable.fr (HELO stedding) ([89.2.94.122]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 11:32:24 +0100 Date: Wed, 07 Feb 2018 10:32:00 -0000 From: Marc Glisse Reply-To: "gcc@gcc.gnu.org" To: Paul Smith cc: "gcc@gcc.gnu.org" Subject: Re: gcc 7.3: Replacing global operator new/delete in shared libraries In-Reply-To: <1517957793.10111.138.camel@mad-scientist.net> Message-ID: References: <1517957793.10111.138.camel@mad-scientist.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2018-02/txt/msg00062.txt.bz2 On Tue, 6 Feb 2018, Paul Smith wrote: > My environment has been using GCC 6.2 (locally compiled) on GNU/Linux > systems. We use a separate heap management library (jemalloc) rather > than the libc allocator. The way we did this in the past was to > declare operator new/delete (all forms) as inline functions in a header Are you sure you still have all forms? The aligned versions were added in gcc-7 IIRC. > and ensure that this header was always the very first thing in every > source file, before even any standard header files. I know that inline > operator new/delete isn't OK in the C++ standard, but in fact it has > worked for us on the systems we care about. Inline usually works, but violating the ODR is harder... I would at least use the always_inline attribute to improve chances (I assume that static (or anonymous namespace) versions wouldn't work), since the optimizer may decide not to inline otherwise. Something based on visibility should be somewhat safer. But it still seems dangerous, some global libstdc++ object might be initialized using one allocator then used with another one... > I'm attempting a toolchain upgrade which is switching to GCC 7.3 / > binutils 2.30 (along with many other updates). > > Now when I run our code, I get a core on exit. It appears an STL > container delete is invoking libc free() with a pointer to memory > allocated by jemalloc. An example would help the discussion. > My question is, what do I need to do to ensure this behavior persists > if I create a global operator new/delete? > > Is it sufficient to ensure that the symbol for our shared library > global new/delete symbols are hidden and not global, using a linker map > or -fvisibility=hidden? I think so (hidden implies not-interposable, so locally bound), but I don't have much experience there. -- Marc Glisse