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.
for ip==0, we sometimes calculate ip-=1.
ip is unsigned, so this is an underflow.
This is not strictly an UB, but more pedantic sanitizers
do catch this and report as possible error.
So why not instead just explicitly set value 0xffff...
(result of 0-1) and avoid this warnings.
This is a breaking change.
The printer now offers a color_mode setting: automatic, always, never.
When given a FILE* stream on linux, the automatic mode will retrieve
file descriptor behind it and call isatty().
Operator names are not supported by MSVC out of the box. Using them
breaks code that needs to build with MSVC and/or (thus) uses
"-fno-operator-names". As a header-only library should pursue maximal
portability, this commit replaces the single usage of operator names
with the more portable operator syntax.
