Revert 126020 - Experiment for updating the tcmalloc chromium branch to r144 (gperftools 2.0).

third_party/tcmalloc/chromium/src/windows/patch_functions.cc

 // Copyright (c) 2007, Google Inc.
 // All rights reserved.
 // 
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 // 
 //     * Redistributions of source code must retain the above copyright
 // notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
@@ skipping 73 matching lines @@
 
 #include <windows.h>
 #include <stdio.h>
 #include <malloc.h>       // for _msize and _expand
 #include <Psapi.h>        // for EnumProcessModules, GetModuleInformation, etc.
 #include <set>
 #include <map>
 #include <vector>
 #include <base/logging.h>
 #include "base/spinlock.h"
-#include "gperftools/malloc_hook.h"
+#include "google/malloc_hook.h"
 #include "malloc_hook-inl.h"
 #include "preamble_patcher.h"
 
 // The maximum number of modules we allow to be in one executable
 const int kMaxModules = 8182;
 
 // These are hard-coded, unfortunately. :-( They are also probably
 // compiler specific.  See get_mangled_names.cc, in this directory,
 // for instructions on how to update these names for your compiler.
 const char kMangledNew[] = "??2@YAPAXI@Z";
@@ skipping 69 matching lines @@
     this->module_base_address_ = that.module_base_address_;
     this->module_base_size_ = that.module_base_size_;
   }
 
   enum {
     kMalloc, kFree, kRealloc, kCalloc,
     kNew, kNewArray, kDelete, kDeleteArray,
     kNewNothrow, kNewArrayNothrow, kDeleteNothrow, kDeleteArrayNothrow,
     // These are windows-only functions from malloc.h
     k_Msize, k_Expand,
-    // A MS CRT "internal" function, implemented using _calloc_impl
-    k_CallocCrt,
     kNumFunctions
   };
 
   // I'd like to put these together in a struct (perhaps in the
   // subclass, so we can put in perftools_fn_ as well), but vc8 seems
   // to have a bug where it doesn't initialize the struct properly if
   // we try to take the address of a function that's not yet loaded
   // from a dll, as is the common case for static_fn_.  So we need
   // each to be in its own array. :-(
   static const char* const function_name_[kNumFunctions];
@@ skipping 203 matching lines @@
   "malloc", "free", "realloc", "calloc",
   kMangledNew, kMangledNewArray, kMangledDelete, kMangledDeleteArray,
   // Ideally we should patch the nothrow versions of new/delete, but
   // at least in msvcrt, nothrow-new machine-code is of a type we
   // can't patch.  Since these are relatively rare, I'm hoping it's ok
   // not to patch them.  (NULL name turns off patching.)
   NULL,  // kMangledNewNothrow,
   NULL,  // kMangledNewArrayNothrow,
   NULL,  // kMangledDeleteNothrow,
   NULL,  // kMangledDeleteArrayNothrow,
-  "_msize", "_expand", "_calloc_crt",
+  "_msize", "_expand",
 };
 
 // For mingw, I can't patch the new/delete here, because the
 // instructions are too small to patch.  Luckily, they're so small
 // because all they do is call into malloc/free, so they still end up
 // calling tcmalloc routines, and we don't actually lose anything
 // (except maybe some stacktrace goodness) by not patching.
 const GenericFnPtr LibcInfo::static_fn_[] = {
   (GenericFnPtr)&::malloc,
   (GenericFnPtr)&::free,
@@ skipping 10 matching lines @@
   (void*(*)(size_t, struct std::nothrow_t const &))&::operator new,
   (GenericFnPtr)
   (void*(*)(size_t, struct std::nothrow_t const &))&::operator new[],
   (GenericFnPtr)
   (void(*)(void*, struct std::nothrow_t const &))&::operator delete,
   (GenericFnPtr)
   (void(*)(void*, struct std::nothrow_t const &))&::operator delete[],
 #endif
   (GenericFnPtr)&::_msize,
   (GenericFnPtr)&::_expand,
-  (GenericFnPtr)&::calloc,
 };
 
 template<int T> GenericFnPtr LibcInfoWithPatchFunctions<T>::origstub_fn_[] = {
   // This will get filled in at run-time, as patching is done.
 };
 
 template<int T>
 const GenericFnPtr LibcInfoWithPatchFunctions<T>::perftools_fn_[] = {
   (GenericFnPtr)&Perftools_malloc,
   (GenericFnPtr)&Perftools_free,
   (GenericFnPtr)&Perftools_realloc,
   (GenericFnPtr)&Perftools_calloc,
   (GenericFnPtr)&Perftools_new,
   (GenericFnPtr)&Perftools_newarray,
   (GenericFnPtr)&Perftools_delete,
   (GenericFnPtr)&Perftools_deletearray,
   (GenericFnPtr)&Perftools_new_nothrow,
   (GenericFnPtr)&Perftools_newarray_nothrow,
   (GenericFnPtr)&Perftools_delete_nothrow,
   (GenericFnPtr)&Perftools_deletearray_nothrow,
   (GenericFnPtr)&Perftools__msize,
   (GenericFnPtr)&Perftools__expand,
-  (GenericFnPtr)&Perftools_calloc,
 };
 
 /*static*/ WindowsInfo::FunctionInfo WindowsInfo::function_info_[] = {
   { "HeapAlloc", NULL, NULL, (GenericFnPtr)&Perftools_HeapAlloc },
   { "HeapFree", NULL, NULL, (GenericFnPtr)&Perftools_HeapFree },
   { "VirtualAllocEx", NULL, NULL, (GenericFnPtr)&Perftools_VirtualAllocEx },
   { "VirtualFreeEx", NULL, NULL, (GenericFnPtr)&Perftools_VirtualFreeEx },
   { "MapViewOfFileEx", NULL, NULL, (GenericFnPtr)&Perftools_MapViewOfFileEx },
   { "UnmapViewOfFile", NULL, NULL, (GenericFnPtr)&Perftools_UnmapViewOfFile },
   { "LoadLibraryExW", NULL, NULL, (GenericFnPtr)&Perftools_LoadLibraryExW },
@@ skipping 345 matching lines @@
   }
   if (new_size == 0) {
     MallocHook::InvokeDeleteHook(old_ptr);
     do_free_with_callback(old_ptr,
                           (void (*)(void*))origstub_fn_[kFree]);
     return NULL;
   }
   return do_realloc_with_callback(
       old_ptr, new_size,
       (void (*)(void*))origstub_fn_[kFree],
-      (size_t (*)(const void*))origstub_fn_[k_Msize]);
+      (size_t (*)(void*))origstub_fn_[k_Msize]);
 }
 
 template<int T>
 void* LibcInfoWithPatchFunctions<T>::Perftools_calloc(
     size_t n, size_t elem_size) __THROW {
   void* result = do_calloc(n, elem_size);
   MallocHook::InvokeNewHook(result, n * elem_size);
   return result;
 }
 
@@ skipping 57 matching lines @@
 // _msize() lets you figure out how much space is reserved for a
 // pointer, in Windows.  Even if applications don't call it, any DLL
 // with global constructors will call (transitively) something called
 // __dllonexit_lk in order to make sure the destructors get called
 // when the dll unloads.  And that will call msize -- horrible things
 // can ensue if this is not hooked.  Other parts of libc may also call
 // this internally.
 
 template<int T>
 size_t LibcInfoWithPatchFunctions<T>::Perftools__msize(void* ptr) __THROW {
-  return GetSizeWithCallback(ptr, (size_t (*)(const void*))origstub_fn_[k_Msize]);
+  return GetSizeWithCallback(ptr, (size_t (*)(void*))origstub_fn_[k_Msize]);
 }
 
 // We need to define this because internal windows functions like to
 // call into it(?).  _expand() is like realloc but doesn't move the
 // pointer.  We punt, which will cause callers to fall back on realloc.
 template<int T>
 void* LibcInfoWithPatchFunctions<T>::Perftools__expand(void *ptr,
                                                        size_t size) __THROW {
   return NULL;
 }
@@ skipping 153 matching lines @@
   if (libc1.is_valid()) libc1.Unpatch();
   if (libc2.is_valid()) libc2.Unpatch();
   if (libc3.is_valid()) libc3.Unpatch();
   if (libc4.is_valid()) libc4.Unpatch();
   if (libc5.is_valid()) libc5.Unpatch();
   if (libc6.is_valid()) libc6.Unpatch();
   if (libc7.is_valid()) libc7.Unpatch();
   if (libc8.is_valid()) libc8.Unpatch();
 }
 #endif