Previously we allowed test programs to be linked at the same time as
weakening is performed, rewriting the .a archives. So lets be more
explicit. We weaken after all-am (which "runs" everything including
libraries and programs), but before all target.
It is kinda minor feature, and apparently we never had it working. But
is a nice to have. Allows our users to override malloc/free/etc while
still being able to link to us (for tc_malloc for example). With
broken weakening we had this use-case broken for static library
case. And it should now work.
somehow VerifyIdentical tests fail for some formatting details. But
since it tests --raw feature of our deprecated perl pprof
implementation, which we don't intend supporting anyways, we drop this
test.
There is some details about how wc -l returns stuff and how zsh uses
it to compare to 3. So we now explicitly strip whitespace and it
works.
OSX has really screwed performance for it's memory allocator due to
their malloc zones stuff. We and our competitors hook into that
facility instead directly overriding allocation functions. Which has
massive performance overhead. This is, apparently, so that malloc is
same as allocating from default zone.
As a result, osx'es C++ operator new/delete performance is even worse.
Because we call operator new, it calls malloc, which calls
malloc_zone_malloc, which calls more stuff and eventually tc_malloc.
Thankfully, for C++ API there is no need for such "integration"
between 'stock' memory allocator and malloc zones stuff. So we can
hook those APIs directly. This speeds up malloc_bench numbers on OSX
about 3x.
This change also unbreaks couple tests (e.g. heap profiler unittest)
which depend on MallocHook_GetCallerStackTrace to return precisely
stack trace up to memory allocator call.
Performance-wise, OSX still lacks good TLS and there is still one jump
indirection even for operator new/delete API due to lack support of
aliases. So Linux or BSD, or even windows would still be significantly
faster on malloc performance on same hardware.
OSX's malloc zones facility is calling 'usable size' before each (!)
free and uses size to choose between our allocator and something
else. And returning 0 breaks this choice. Which happens if we got
0-sized malloc request, which our tests exercise couple times. So we
don't let debug allocator on OSX to have 0 sized chunks. This unbreaks
debug allocation tests on OSX.
On OSX we hook into "system's" malloc through this zones facility, so
we need to place those those interface functions into google_malloc
section. This largely unbreaks MallocHook_GetCallerStackTrace on OSX.
For some reason clang shipped with osx miscompiles LowLevelAlloc when
it tries to place Alloc methods into malloc_hooks section. But since
we don't really need that placement on OSX, we can simply drop that
section placement.
In most practical terms, this expands "official" heap leak checker
support to Linux/arm64 and Linux/riscv (mips-en and legacy arm are
likely to work & pass tests too now).
The code is now explicitly Linux-only, without trying to pretend
otherwise. Main goal of this change is to finally amputate
linux_syscall_support.h, which we historically had trouble maintaining
well. Biggest challenge was around thread listing facility which uses
clone (ptrace explicitly fails between threads) and that causes
difficulties around parent and child tasks sharing
errno. linux_syscall_support stuff had special feature to "redirect"
errno accesses. But it caused us for more trouble. We switched to
regular syscalls, and errno stamping avoidance is now simply via
careful programming.
A number of other cleanups is made (such us thread finding codes in
procfs which clearly was built for some ages old and odd kernels).
sem_post/sem_wait synchronization was previously potentially prone to
deadlock (if parent died at bad time). We now use pipe pair for this
synchronization and it is fully robust.
I.e. all recent compilers (both gcc and clang) optimize out delete(new
int) sequence to nothing. We call to tc_new and tc_delete directly to
suppress this optimization.
First, ml64 (amd64 version of masm) doesn't support /coff. Second, it
also doesn't support (nor use) .model directive.
Sadly, asm is inherently amd64-only, so this entire test won't build
in i386 configuration.
This makes our code one step closer to killing unportable custom
atomics implementation. I did manually inspect generated code that
fast-path is identical and slow path's changes of generated code are
cosmetic.
Somehow I originally choose to segfault to test this, and it caused us
to deal with 'skipping over' null pointer access. Which ended up not
so easy to do semi-portably. But easier way is to do same
itimer/sigprof thing that we do in actual profiler.
We're still somewhat at the mercy of compiler placing code "normally",
but this implementation seems more robust anyways.
Many our unit tests require specific stack traces or that
allocation/deallocation is not elimininated. As compilation gets more
aggressive (such as when cross-object optimization is enabled during
LTO), we break more of those cases.
This commit extends noopt usage that disables inlining optimization in
specific cases. This fixes github issue #1358.
It is required for LTO builds, specifically it fixes
stacktrace_unittest. This is because API of stacktrace capturing
functions implicitly assumes that those are not inlined.
Refers to github issue #1358.
Previously we blindly tried to use libunwind whenever header is
detected. Even if actually working libunwind library is missing. This
is now fixed, so we attempt to use libunwind when it actually works.
Somehow recent freebsd ships libunwind.h (which seems to belong to
llvm's implementation), but apparently without matching .so. So then building
and linking failed.
We got bitten again by compiler optimizing out free(malloc(sz))
combination. We replace calls to malloc/free with calls to global
function operator new/delete. Those are apparently forbidden by
standard to be optimized out.
If for some reason benchmark function is too fast (like when it got
optimized out to nothing), we'd previously hang in infinite loop. Now
we'll catch this condition due to iterations count overflowing.
On modern machines xoring volatile int is fast enough to occasionally
make specific test case's profiling results not stable enough. So we
now force atomics into the picture which is slightly slower (could be
lots on some platforms and/or optimizer flags).
As part of that we also upgrade required autoconf version to 2.69
which is what I see in rhel/centos 7 and ubuntu 14.04. Both are old
enough. And, of course, .tar.gz releases still ship "packaged" configure,
so will work on older distros.
This fixes issue #1335.
