[PATCH] Slightly better way to __USE_MALLOC

[Brad Spencer]

On Thu, Oct 10, 2002 at 11:56:57AM -0300, Brad Spencer wrote:
> > However, I am afraid that you didn't test well enough the various
> > cases which exist.  Please try compiling your posted test case at -O2
> > (and of course removing the c++config check I added, and as you
> > propose to do with your patch).  The program is linkable without an
> > error yet there is a mismatch between memory allocation
> > implementations.  I will post a multi-file test case which blows up
> > when compiled in a mismatched manner, if it will help you fully
> > understand the broader issue.

I was able to reproduce the problem after all.  The goal has to be to
emit an undefined symbol into every object file that "tags" it as
being compiled against one or the other ABI.  I'm trying to work out
different ways to do this and then choose the one with the minimal
side effects (i.e. runtime cost, etc).

Here are the options I have come up with so far.

1) Declare per-allocator-style classes and instantiate one per object
   (via a static definition) but don't define the (no-op) constructor
   except in stl-inst.cc.  This works, but the constructor gets called
   once per object file at program start :(

   Here's a quick summary of the additional changes required.

In stl-inst.cc:

  // This will cause linker errors if the user tries to mismatch
  // an allocator-using program and library.  That is good.
#ifdef _GLIBCPP_USE_MALLOC
  template class __malloc_alloc_template<0>;
  __use_malloc_allocator_abi::__use_malloc_allocator_abi() {}
#else
  template class __default_alloc_template<true, 0>;
  __use_default_allocator_abi::__use_default_allocator_abi() {}
#endif
   
In stl_alloc.h:

  // Declare a dummy class and instantiate it in every object file to
  // ensure that code compiled with _GLIBCPP_USE_MALLOC can't compile 
  // against  a library that's not, and vice versa.
#ifdef _GLIBCPP_USE_MALLOC
struct __use_malloc_allocator_abi { __use_malloc_allocator_abi(); }
static __use_malloc_allocator_abi;
#else
struct __use_default_allocator_abi { __use_default_allocator_abi(); }
static __use_default_allocator_abi;
#endif

  I think the runtime invocation of the dummy function makes this
  solution undesirable, even if it is just at startup.
   
2) This is a lighter-weight version of option #1.  Instead of using
   classes and constructors, just use integers and pointers to them.
   Introduce a pointer in each object that must reference a const int
   that lives in the library.  A mismatch between memory allocators
   introduces a mismatch between the integer symbol names, and linking
   fails.

   Here's a quick summary of the changes required for this case.

In stl-inst.cc:

  // This will cause linker errors if the user tries to mismatch
  // an allocator-using program and library.  That is good.
#ifdef _GLIBCPP_USE_MALLOC
  template class __malloc_alloc_template<0>;
  extern const int __use_malloc_allocator_abi = 0;
#else
  template class __default_alloc_template<true, 0>;
  extern const int __use_default_allocator_abi = 0;
#endif

In stl_alloc.h:

  // Declare an initialized dummy int* in every object file to
  // ensure that code compiled with _GLIBCPP_USE_MALLOC can't compile 
  // against  a library that's not, and vice versa.  The initial value
  // is only present a library compiled with the same 
  // _GLIBCPP_USE_MALLOC setting.
#ifdef _GLIBCPP_USE_MALLOC
  extern const int __use_malloc_allocator_abi;
  static const int* __allocator_abi_in_use =
  &__use_malloc_allocator_abi;
#else
  extern const int __use_default_allocator_abi;
  static const int* __allocator_abi_in_use =
  &__use_default_allocator_abi;
#endif

  I think this is better because I think the linker does all the
  work.  Or do these pointers still get set during static 
  initialization and construction? 

Is there a cleaner, simpler way to introduce such a symbol?  Are
either of these acceptable?

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company