← Back to branch summary

~ubuntu-branches/ubuntu/jaunty/google-perftools/jaunty

« back to all changes in this revision

Viewing changes to src/windows/vc7and8.def

  • Committer: Bazaar Package Importer
  • Author(s): Daigo Moriwaki
  • Date: 2008-06-15 23:41:36 UTC
  • mfrom: (3.1.1 sid)
  • Revision ID: james.westby@ubuntu.com-20080615234136-al5gawvdvt5vhdtz
Tags: 0.98-1
http://bugs.debian.org/425147
http://bugs.debian.org/454841
http://bugs.debian.org/450294
http://bugs.debian.org/404001
* New upstream release. (Closes: #425147)
* Compiled with GCC 4.3. (Closes: #454841)
* debian/watch: can now report upstream's version (Closes: #450294)
* Because of a file conflict between tau and libgoogle-perftools the
  binary pprof is renamed as google-pprof. (Closes: #404001)
  Great thanks to Michael Mende.
* debian/rules: autoconf files are now generated at the build time.
* Bumped up Standards-Version to 3.7.3, no changes are required.
* Split a new package, libtcmallc_minimal0. The upstream supports
  this module for wider platforms. So I leave its architecture to be
  `any'.
* libgoogle-perftools0's architecture is now i386. The upstream
  supports this module for x86 and x86_64. However, x86_64 requires
  libunwind's development head, which Debian does not have yet.
* Removed an unnecessary patch, debian/patches/02_profiler.cc_alpha.diff.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/windows/vc7and8.def
 
1
;; Most symbols in the google-perftools dll are exported via
 
2
;; __declspec(dllexport).  This works fine for functions we're
 
3
;; defining ourselves, but not for functions we're overriding, like
 
4
;; malloc, free, and new.  Those already have an export spec in
 
5
;; msvcrt.dll.  (In particular, they're already declared internally in
 
6
;; a header that exists in the compiler's own static data, and there's
 
7
;; no way to override inclusion of that header.)  Since that header
 
8
;; doesn't declare these functions dllexport, we can't redeclare them
 
9
;; dllexport.
 
10
;;
 
11
;; For malloc, calloc, realloc, and free, not only can we not override
 
12
;; the declaration, we can't override the definition: windows does not
 
13
;; provide "weak" linkage for these functions (in general).
 
14
;; The way we deal with these functions in code is to patch the
 
15
;; assembly code for the Windows malloc/etc to point to our
 
16
;; functions.  Using this technique, there's no need to declare our
 
17
;; own version of malloc/etc anywhere: we do our own "exporting" when
 
18
;; we patch up the assembly code.
 
19
;;
 
20
;; For new and delete, we *can* override the definition.  That means
 
21
;; we need to export our declaration.  As mentioned, we can't
 
22
;; redeclare them dllexport in our .h file.  The only other way to
 
23
;; export a declaration is to declare it here, in a .def file.
 
24
;; We export the 4 versions of new and delete that  we override:
 
25
;;     ??2@YAPAXI@Z    (void * __cdecl operator new(unsigned int))
 
26
;;     ??3@YAXPAX@Z    (void __cdecl operator delete(void *))
 
27
;;     ??_U@YAPAXI@Z   (void * __cdecl operator new[](unsigned int))
 
28
;;     ??_V@YAXPAX@Z   (void __cdecl operator delete[](void *))
 
29
;;     ??2@YAPAXIABUnothrow_t@std@@@Z    (void * __cdecl operator new(unsigned int,struct std::nothrow_t const &))
 
30
;;     ??3@YAXPAXABUnothrow_t@std@@@Z    (void __cdecl operator delete(void *,struct std::nothrow_t const &))
 
31
;;     ??_U@YAPAXIABUnothrow_t@std@@@Z   (void * __cdecl operator new[](unsigned int,struct std::nothrow_t const &))
 
32
;;     ??_V@YAXPAXABUnothrow_t@std@@@Z   (void __cdecl operator delete[](void *,struct std::nothrow_t const &))
 
33
;;
 
34
;; (The first field is the mangled name, and the stuff in parens is
 
35
;; the unmangled name.  Mangling can change from compiler-version to
 
36
;; compiler-version; the mangling above is good for at least VC++ 7.1
 
37
;; and VC++ 8.0.)
 
38
;;
 
39
;; To figure out the mangled names, I compiled tcmalloc.obj
 
40
;; (tcmalloc.cc is the file that overrides these operators), and ran
 
41
;; "dumpbin /symbols" on tcmalloc.obj.  I then did a grep (in unix :-) )
 
42
;; over the output, looking for "operator".  This showed the 8
 
43
;; operator new and operator delete calls in tcmalloc.cc, plus a
 
44
;; placement new and placement delete that I ignored.
 
45
;;
 
46
;; Finally, for the memory-allocation routines that tcmalloc defines
 
47
;; but windows doesn't -- cfree, posix_memalign, etc -- I *could* put
 
48
;; a dllexport in the .h file where I declare them, since there's no
 
49
;; windows declaration to worry about.  But I put them here instead,
 
50
;; partly to avoid the extra verbiage in the source code, and partly
 
51
;; to keep all the export info for the memory-allocation functions
 
52
;; together.
 
53
 
 
54
EXPORTS
 
55
  ??2@YAPAXI@Z
 
56
  ??3@YAXPAX@Z
 
57
  ??_U@YAPAXI@Z
 
58
  ??_V@YAXPAX@Z
 
59
  ??2@YAPAXIABUnothrow_t@std@@@Z
 
60
  ??3@YAXPAXABUnothrow_t@std@@@Z
 
61
  ??_U@YAPAXIABUnothrow_t@std@@@Z
 
62
  ??_V@YAXPAXABUnothrow_t@std@@@Z
 
63
  cfree
 
64
  posix_memalign
 
65
  memalign
 
66
  valloc
 
67
  pvalloc