We previously had logic to compute the base address from program
headers as part of symbolization. The problem is that we need a correct
base address earlier in order to adjust a PC into the image's address
space, as these addresses can appear in unsymbolized output.
There was previously an assumption that only the mapping that
was lowest in the address space did not need to be adjusted. This
assumption is not guaranteed (for example, the kernel may choose to
map an ET_DYN lowest) and in fact turned out to be wrong in binaries
linked with lld because the first mapping is read-only.
The solution is to move the program header reading logic into the
code that reads /proc/self/maps.
There is a change in semantics for clients that install a callback
using the InstallSymbolizeOpenObjectFileCallback function. Any such
clients will need to return a correct base address from the callback
by reading program headers using code similar to that in the function
OpenObjectFileContainingPcAndGetStartAddress.
Glog uses a pre-C++11 compile time assert to verify the validity of
the severity parameter for LOG_EVERY_N. Unfortunately, some compilers
will complain about the usage of LOG_EVERY_N with
"-Wunused-local-typedef" due to the way the compile time assert is
constructed. This makes it impossible to use LOG_EVERY_N with this
warning treated as an error.
The fix simply removes the assert entirely. This is safe to do since
you can't put anything invalid into the severity parameters without
generating a compile error elsewhere. This has been safe to do ever
since the GLOG_ prefixes were added as part of 6febec361e.
Fixes#223
Commit changes to src/windows/glog/logging.h that were missed in
2df0ca34aa. Because a change to src/glog/logging.h.in was made,
src/windows/preprocess.sh needed to be run.
Don't rely on an internal-linkage extern "C" function having an
unmangled name. This isn't required by the ABI, and in fact is not
valid for a conforming compiler(!). Instead, allow symbolization to
produce either a mangled or an unmangled name here.
The macro NDEBUG could be automatically defined for release build on
some build environments (e.g. MSVC). If we use NDEBUG as a key to
distinguish using DCHECK as CHECK (I call this DCHECK is enabled) or
not, we cannot make DCHECK enabled for release build on such
environments.
Considering people use a program with glog for presubmit testing or
dogfooding, they should need to do release build with DCHECK enabled.
There can be a large kernel overhead involved in POSIX_FADV_DONTNEED.
There is no point in calling this per item logged, so rate limit
to at most once per 2MiB written.
With a simple test program that logs 100K items at WARNING level:
Before:
$ time strace -c -e fadvise64 log.test \
-log_dir=/dev/shm -logtofiles=true -logtostderr=false
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 12.522509 125 99957 fadvise64
------ ----------- ----------- --------- --------- ----------------
real 0m52.671s
user 0m2.194s
sys 0m44.022s
After:
$ time strace -c -e fadvise64 log.test \
-log_dir=/dev/shm -logtofiles=true -logtostderr=false
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.000759 152 5 fadvise64
------ ----------- ----------- --------- --------- ----------------
real 0m4.206s
user 0m1.436s
sys 0m3.153s
Fixes issue #84
It looks like commit 3c49b93 modified the auto-generated file src/config.h.in
to add a definition of macro GOOGLE_GLOG_DLL_DECL. One of the autotools
reverts this change upon running "make", causing the build to fail when a
source file includes demangle.h.
To fix the problem, revert the change to src/config.h.in and include
glog/logging.h from demangle.h which provides a definition of that macro.
Previously we were using a module's "start address", i.e. the
address at which the module's executable region was mapped, as the
zero virtual address, i.e. the address from which the DSO's virtual
addresses are calculated. This works fine for DSOs created by the
bfd and gold linkers, which will emit a PT_LOAD directive into the
program header which loads the executable region at virtual address
(p_vaddr) and file offset (p_offset) 0.
However, the lld linker may place a read-only region before the
executable region, meaning that both p_vaddr and p_offset for the
executable region are non-zero. This means that any symbols resolved
by the symbolizer are resolved to an incorrect virtual address. To
correctly calculate the address corresponding to virtual address zero,
we need to take into account p_vaddr and p_offset.
Specifically, the calculation starts with the "base address", i.e. the
start address minus the file offset. To get from the base address to
virtual address zero, we first add p_offset. This gives us the mapped
address of the start of the segment, or in other words the mapped
address corresponding to the virtual address of the segment. (Note
that this is distinct from the start address, as p_offset is not
guaranteed to be page aligned.) We then subtract p_vaddr, which takes
us to virtual address zero.
