Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-08 Thread Paul Smith
On Wed, 2018-02-07 at 19:26 -0500, Paul Smith wrote: > Thanks for the conversation. I'm moving forward with a real global > operator new/delete and working out the magic needed to ensure those > symbols are not global in our shared library. I remember one annoying thing I ran into: through

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Paul Smith
On Thu, 2018-02-08 at 01:17 +0100, Marc Glisse wrote: > On Wed, 7 Feb 2018, Paul Smith wrote: > > > > 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 >

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Paul Smith
On Wed, 2018-02-07 at 16:38 -0700, Martin Sebor wrote: > I'm not sure I see how defining operator new inline can work > unless you recompile the world (i.e., all the DSOs used by > the program, including libstdc++). As Marc already hinted, > if libstdc++ dynamically allocates an object using the

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Marc Glisse
On Wed, 7 Feb 2018, Paul Smith wrote: 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

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Jonathan Wakely
On 7 February 2018 at 23:38, Martin Sebor wrote: > On 02/06/2018 03:56 PM, Paul Smith wrote: >> >> Hi all. >> >> Hopefully this isn't too annoying a question :). >> >> My environment has been using GCC 6.2 (locally compiled) on GNU/Linux >> systems. We use a separate heap management library

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Martin Sebor
On 02/06/2018 03:56 PM, Paul Smith wrote: Hi all. Hopefully this isn't too annoying a question :). 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

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Paul Smith
On Wed, 2018-02-07 at 11:32 +0100, Marc Glisse wrote: > 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

Re: gcc 7.3: Replacing global operator new/delete in shared libraries

2018-02-07 Thread Marc Glisse
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