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.
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.
It is actually needed for libgcc backtracer from time to time. And
we've seen libunwind to need it too. Plus we've not heard of any
problems with it. So lets just always enable it.
This should fix github issue #1248.
Previously it only was respected on x86_64, but this days lots of modern
ABIs are without frame pointers by default (e.g. arm64 and riscv, and
even older mips).
__sbrk is not defined in musl so add a check for it in configure.ac and
replace the check on ifndef __UCLIBC__ by a check on ifdef HAVE__SBRK
in src/malloc_hook_mmap_linux.h
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Everyone should be using golang pprof from github.com/google/pprof, but
distros still ship our perl version and not everyone is aware of
better pprof yet.
This is another step in completely dropping perl pprof. We still
default to installing it, but hopefully we'll be able to convince
distros to disable this soon.
We still install pprof under pprof-symbolize name because
stack traces symbolization depends on it, and because golang pprof
won't support this feature.
This is related to issue #1038.
As reported in issue #954, osx clang compiler is able to optimize our
previous detection away while not really having runtime support for
sized delete. So this time we use AC_LINK_IFELSE and more robust code
to prevent compiler from optimizing away sized delete call. This
should reliably catch "bad" compilers.
Special thanks to Alexey Serbin for reporting the issue, suggesting a
fix and verifying it.
Fixes issue #954.
- Add auto-detection of std::align_val_t presence to configure scripts. This
indicates that the compiler supports C++17 operator new/delete overloads
for overaligned types.
- Add auto-detection of -faligned-new compiler option that appeared in gcc 7.
The option allows the compiler to generate calls to the new operators. It is
needed for tests.
- Added overrides for the new operators. The overrides are enabled if the
support for std::align_val_t has been detected. The implementation is mostly
based on the infrastructure used by memalign, which had to be extended to
support being used by C++ operators in addition to C functions. In particular,
the debug version of the library has to distinguish memory allocated by
memalign from that by operator new. The current implementation of sized
overaligned delete operators do not make use of the supplied size argument
except for the debug allocator because it is difficult to calculate the exact
allocation size that was used to allocate memory with alignment. This can be
done in the future.
- Removed forward declaration of std::nothrow_t. This was not portable as
the standard library is not required to provide nothrow_t directly in
namespace std (it could use e.g. an inline namespace within std). The <new>
header needs to be included for std::align_val_t anyway.
- Fixed operator delete[] implementation in libc_override_redefine.h.
- Moved TC_ALIAS definition to the beginning of the file in tcmalloc.cc so that
the macro is defined before its first use in nallocx.
- Added tests to verify the added operators.
[alkondratenko@gmail.com: fixed couple minor warnings, and some
whitespace change]
[alkondratenko@gmail.com: removed addition of TC_ALIAS in debug allocator]
Signed-off-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
This reverts commit b82d89cb7c.
Dynamic sized delete support relies on ifunc handler being able to
look up environment variable. The issue is, when stuff is linked with
-z now linker flags, all relocations are performed early. And sadly
ifunc relocations are not treated specially. So when ifunc handler
runs, it cannot rely on any dynamic relocations at all, otherwise
crash is real possibility. So we cannot afford doing it until (and if)
ifunc is fixed.
This was brought to my attention by Fedora people at
https://bugzilla.redhat.com/show_bug.cgi?id=1452813
Apparently gcc only supports __attribute__((aligned(N))) on functions
only since version 4.3. So lets test it in configure script and only
use when possible. We now use CACHELINE_ALIGNED_FN macro for aligning
functions.
I got report that some build environments for
https://github.com/lyft/envoy are having link-time issue due to
linking libunwind. It was happening despite libunwind.h being present,
which is clear bug as without header we won't really use libunwind.
