1. 22 Jun, 2017 2 commits
  2. 12 May, 2017 2 commits
  3. 10 May, 2017 2 commits
  4. 09 May, 2017 8 commits
  5. 21 Apr, 2017 1 commit
  6. 20 Apr, 2017 1 commit
  7. 07 Mar, 2017 2 commits
  8. 09 Feb, 2017 1 commit
  9. 08 Feb, 2017 1 commit
    • Yoshisato Yanagisawa's avatar
      DCHECK_ALWAYS_ON to make D* enabled under NDEBUG · 027332ff
      Yoshisato Yanagisawa authored
      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.
      027332ff
  10. 20 Oct, 2016 1 commit
  11. 19 Oct, 2016 11 commits
  12. 07 Oct, 2016 2 commits
  13. 03 Oct, 2016 1 commit
  14. 11 Sep, 2016 1 commit
  15. 14 Jul, 2016 2 commits
  16. 23 Jun, 2016 2 commits
    • Peter Collingbourne's avatar
      Fix autotools build. · 8e98eb2a
      Peter Collingbourne authored
      It looks like commit 3c49b932 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.
      8e98eb2a
    • Peter Collingbourne's avatar
      symbolize: Calculate a module's zero VA using program headers. · a93a4511
      Peter Collingbourne authored
      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.
      a93a4511