As long as symbols have the right declspec, the linker is going to
export them as expected. The main exception to when we actually need the
exported symbol to have a different name, which is the case for the
symbols normally exported by the CRT. So keep only those renamed symbols
in mozglue.def.in.
Keeping the jemalloc symbols in this file kind of implies that we need
every new API entry points to appear in there when it's not true. This
thus removes an unnecessary moving part when adding new allocator API
entry points.
--HG--
extra : rebase_source : 76faa659d62d46f3624fe3f1df0c09beb68e3549
For obscure linkage reasons, we need all the replace-malloc symbols
being passed to the linker to tell it to allow them being undefined.
That list actually duplicates what's in malloc_decls.h somehow, and
every time we add an entry point, we end up having to modify those two
files (and others, addressed in different bugs), which is suboptimal.
So we generate the list of those symbols from malloc_decls.h.
--HG--
extra : rebase_source : 50156c6dda5601a6437f94a753400ec4ed9c8343
jemalloc_ptr_info() gives info about any pointer, such as whether it's within a
live or free allocation, and if so, info about that allocation. It's useful for
debugging.
moz_malloc_enclosing_size_of() uses jemalloc_ptr_info() to measure the size of
an allocation from an interior pointer. It's useful for memory reporting,
especially for Rust code.
--HG--
extra : rebase_source : caa19cccf8c2d1f79cf004fe6a408775de5a7b22
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 27b1dda404b3fc5fab95dd524677387bad921751
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 1039c3f8669093c9d77a3c30090c76457c8eb6e8
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : d932e84ff0729b1c5ccff6658ee81849eb27eef4
Bug 1186064 removed most of it when we started requiring VS 2015u2, but
the "frex" function exported through mozglue.def.in was only used
through the MSVCRT being patched by fixcrt.py, which is not done anymore.
So the "frex" export is not used anymore, and so the "dumb_free_thunk"
function is not used anymore as well.
--HG--
extra : rebase_source : 879c469c317c8b6749410a4a476d6c951c9a1d0f
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
EnsureWalkThreadReady takes two locks, one in _beginthreadex and another in the DLL hook setup.
We can avoid the first by not calling EnsureWalkThreadReady if we're walking a suspended thread, since we won't be using a separate WalkThread anyway.
To avoid the hook locks, I gave in and decided to go back to setting up the hooks in DllBlocklist_Initialize as originally planned.
This avoids many additions of `extern "C"` in C++ code and will avoid
having to do the same to mozjemalloc once built as C++.
--HG--
extra : rebase_source : af55696262f40a9dd16a19c29edcb9bb307d4957
This avoids many additions of `extern "C"` in C++ code and will avoid
having to do the same to mozjemalloc once built as C++.
--HG--
extra : rebase_source : af55696262f40a9dd16a19c29edcb9bb307d4957
aarch64's gcc and arm's gcc with -mfpu=neon defines __ARM_NEON for NEON, so we should detect it to support NEON code.
MozReview-Commit-ID: LRMTQLctuLV
--HG--
extra : rebase_source : 9e09eb9b67824c81dc45198acd6582584a5e1652
Marco Castelluccio
Bob Owen
Mike Hommey
Sebastian Hengst
Christian Holler
Chris Manchester
Julien Cristau
Wes Kocher
Nicholas Nethercote
Tom Ritter
Ryan VanderMeulen
Carl Corcoran
David Major
Ehsan Akhgari
Carsten "Tomcat" Book
Makoto Kato
Julian Seward
Aaron Klotz
Franziskus Kiefer