This is useful for binaries (using backward-cpp) that are built with
relative source file paths. In such a situation, backward-cpp will
generally not be able to locate the source files. This change allows
the user to specify a delimited list of search paths in the following
environment variable:
BACKWARD_CXX_SOURCE_PREFIXES
The paths are separated by semicolons on Windows and colons otherwise.
When the environment variable is set, those search paths will be tried
first. If they do not yield any valid files then backward-cpp will
fall back to current behavior.
MIPS didn't export regs at mcontext_t so we need to cast it as sigcontext.
All test passed on my mips64el machine.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Linux is not synonymous with glibc. Alpine linux (among others) uses
libmusl as the standard C library. Alpine/libmusl doesn't have
backtrace, dladdr1, execinfo.h or error.h. It does have libunwind
and program_invocation_name and libdwarf and libelf are available as
packages.
This patch makes backward-cpp work on Alpine linux (and hopefully
others that rely on libmusl).
This patch makes dladdr1 dependent on the __GLIBC__ pp-symbol
(rather than __ANDROID__).
It uses __has_include (protected by a defined()) rather than __APPLE__
to decide whether to include <error.h> in _test_main.cpp.
returning a `const T` as opposed to `const T&` serves little purpose and is most likely not what the writer intended.
This change was called out by clang-tidy.
When iterating through all the CU DIEs, only inspect those that have the
DW_TAG_compile_unit tag. When finishing the iteration, only keep going
to reset libdwarf's internal CU iterator if we found a DIE.
Some compiler flags and/or compilers will set this instead. There are
undoubtedly others but I know this fixes my problem.
The flag that I'm currently seeing alter this is `-std=c++0x`.
Signed-off-by: Christy Norman <christy@linux.vnet.ibm.com>
On some platforms we got a warning about 'info' not being used because the #if _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L was not true. Can't remember which platform right now but this patch addressed it.
GCC shows warnings (like:
warning: 'virtual std::streamsize backward::cfile_streambuf::xsputn(const char_type*, std::streamsize)' can be marked override [-Wsuggest-override]
In the cfile_streambuf class. This patch #defines override to be nothingness in C++98 and adds the override keyword to the functions with the warnings.
* functional mac port
* combine common parts of Linux and Darwin implementations
* add unwind support for apple
* insure BACKWARD_HAS_BACKTRACE_SYMBOL is set for BACKWARD_SYSTEM_DARWIN
* fix indentation
* use pthread_self and pthread_main_np
If an executable is run by e.g. being on the PATH (anything that results in argv[0] not being a valid
path to the executable), problems ensue when backward-cpp tries to print a stack trace.
dladdr returns argv[0] in dli_fname for symbols contained in the main executable, which is not a valid
path if the executable was found by a search of the PATH environment variable. Then, load_object_with_bfd
is called on that non-existent filename and fails.
The implemented solution is to detect `dladdr` returning `argv[0]` and replace it with the executable's
path, read from the /proc/self/exe symlink.
In our code, we need to take certain cleanup actions
after receiving a SIGSEGV. This makes it difficult to
integrate with backward, as our custom sighandler is overriden.
A simple solution is to have backward-cpp expose the
core sighandling logic as a public function, which
we can simply call from within our code. This is not
currently possible since sig_handler is private, and
additionally raises the signal again at the end.
This pull request makes the above possible. The alternative
is to copy handleSignal into our own code, which is just ugly.
*Read the pc as specified for aarch64 processors.
*Disable division by zero tests, since aarch64 does not trap these and
therefore does not generate SIGFPEs there.
*All other tests succeed.
