Added
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
to the beginning of all source files that didn't have it.
This ensures that configuration options are respected in all source
files. In particular, it ensures that the defines needed to fix Large
File System issues are set before including system headers.
More generally, it ensures consistency between the source files, and
avoids the possibility of ODR violations between source files that were
including config.h and source files that were not.
Process:
Ran
find . \( -name third_party -prune \) -o \( -name '.git*' -prune \) -o \( \( -name '*.cc' -o -name '*.c' \) -exec sed -i '0,/^#include/ s/^#include/#ifdef HAVE_CONFIG_H\n#include <config.h> \/\/ Must come first\n#endif\n\n#include/' {} + \)
and then manually fixed up src/common/linux/guid_creator.cc,
src/tools/solaris/dump_syms/testdata/dump_syms_regtest.cc,
src/tools/windows/dump_syms/testdata/dump_syms_regtest.cc,
src/common/stabs_reader.h, and src/common/linux/breakpad_getcontext.h.
BUG=google-breakpad:877
Fixed: google-breakpad:877
TEST=./configure && make && make check
TEST=Did the find/sed in ChromeOS's copy, ensured emerge-hana google-breakpad
worked and had fewer LFS violations.
TEST=Did the find/sed in Chrome's copy, ensured compiling hana, windows, linux, and
eve still worked (since Chrome doesn't used config.h)
Change-Id: I16cededbba0ea0c28e919b13243e35300999e799
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4289676
Reviewed-by: Mike Frysinger <vapier@chromium.org>
sed -i '' -E -e 's/Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*(\r)?$/Copyright \2 Google LLC\4/' -e '/^((\/\/|#| \*) )?All rights reserved\.?\r?$/d' -e 's/name of Google Inc\. nor the/name of Google LLC nor the/' -e 's/POSSIBILITY OF SUCH DAMAGE$/POSSIBILITY OF SUCH DAMAGE./' $(git grep -El 'Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*$')
Plus manual fixes for src/processor/disassembler_x86.{cc,h}.
Plus some conversions from CRLF to LF line endings in .cc and .h files.
Bug: chromium:1098010
Change-Id: I8030e804eecd9f5a1ec9d66ae166efd8418c2a67
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3878302
Reviewed-by: Mike Frysinger <vapier@chromium.org>
macho_reader assumes that every section in a segment exists, or none of the
sections exist in the file (for dSYM files).
https://reviews.llvm.org/D94460?id=315965 added __eh_frame section to the
__TEXT segments in dSYM files. All the other sections are removed, but still
have non-zero size in the header. macho_reader only looks at `fileoff` and
`filesize` fields to determine the size of the segment, but it looks at `addr`
and `size` to determine the size of the section, therefore it determines that
the sections would not fit in the segment and refused to parse the file.
In this case the removed sections all have offset == 0. Ignore such cases.
Change-Id: Ife771f7b302c1bc81c673b1103492c41321b5e3e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2911204
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
We do this in a lot of places, but we're inconsistent.
Normalize the code to the Google C++ style guide.
Change-Id: Ic2aceab661ce8f6b993dda21b1cdf5d2198dcbbf
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2262932
Reviewed-by: Sterling Augustine <saugustine@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Even 64-bit Mach-O (MH_MAGIC_64 = 0xfeedfacf) is not a fully 64-bit file
format. File offsets in sections are stored in 32-bit fields, with
Mach-O writers typically truncating offsets too large to fit to just
their low 32 bits. When a section begins at a file offset >= 4GB,
dump_syms would produce an error such as:
Google Chrome Framework.dSYM/Contents/Resources/DWARF/Google Chrome Framework: the section '__apple_names' in segment '__DWARF' claims its contents lie outside the segment's contents
As a workaround, this implements the strategy I first described in
https://crbug.com/940823#c22.
Segment file offsets are stored in 64-bit fields. Because segments
contain sections and must load contiguously, it’s possible to infer a
section’s actual offset by computing its load address relative to its
containing segment’s load address, and treating this as an offset into
the containing segment’s file offset. For safety, this is only done for
64-bit segments (LC_SEGMENT_64) where the 32-bit section offset stored
in the Mach-O file is equal to the low (truncated) 32 bits of the
section offset recomputed per the above strategy.
Beware that this does not provide full “large file” support for 64-bit
Mach-O files. There are other file offsets within Mach-O files aside
from section file offsets that are stored in 32-bit fields even in the
64-bit format, including offsets to symbol table data (LC_SYMTAB and
LC_DYSYMTAB). No attempt is made to recover correct file offsets for
such data because, at present, such data is always stored by dsymutil
near the beginning of .dSYM files, within the first 4GB. If it becomes
necessary to address these other offsets, it should be possible to
recover these offsets by reference to the __LINKEDIT segment that
normally contains them, provided that __LINKEDIT doesn’t span more than
4GB, according to the strategy discussed at the bottom of
https://crbug.com/940823#c22.
Although this is sufficient to allow dump_syms to interpret Chromium
.dSYM files that exceed 4GB, be warned that these Mach-O files are still
technically malformed, and most other tools that consume Mach-O files
will continue to have difficulties interpreting these large files.
As further warning, note that should any individual DWARF section exceed
4GB, internal section offsets will be truncated irrecoverably, unless
and until the toolchain implements support for DWARF64.
https://bugs.llvm.org/show_bug.cgi?id=14969
With this change, dump_syms is able to correctly recover file offsets
from and continue processing a .dSYM file with length 4530593528
(4321MB), whose largest section (__DWARF,__debug_info = .debug_info) has
size 0x8d64c0b8 (2262MB), and which contains four sections (starting
with __DWARF,__apple_names) beginning at file offsets >= 4GB.
Bug: chromium:940823, chromium:946404
Change-Id: I23f5f3b07773fa2f010204d5bb53b6fb1d4926f7
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1541830
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This patch allows dump_syms to handle S_THREAD_LOCAL_ZEROFILL
and S_GB_ZEROFILL section in the same way as the more common
S_ZEROFILL section. Previously, dump_syms would fail to dump
a binary containing a __DATA,__thread_bss section, because it
tried to look up its data (and failed).
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1369233003 .
Patch from Pavel Labath <labath@google.com>.
In my testing, ARM V8 object files and ARM V8 slices of universal binaries do
not contain debug_frame sections (at least at this time), and hence dump_syms
does not output CFI for ARM V8 even in the absence of the "-c" flag.
Patch by:blundell@chromium.org
BUG=542
R=qsr@chromium.org
Review URL: https://breakpad.appspot.com/642002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1222 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch adds files defining new classes in the google_breakpad::Mach_O
namespace for parsing fat binaries and Mach-O files. These are used in the
new dumper to handle STABS debugging information, DWARF call frame
information, and .eh_frame exception handling stack walking information.
These new classes are independent of endianness and word size, and
therefore can be used on binaries of all the relevant architectures: x86,
x86_64, ppc, and ARM.
The patch adds a complete set of unit tests for the new classes.
A=jimb R=mark (http://breakpad.appspot.com/93001/show, http://breakpad.appspot.com/115001/show)
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@610 4c0a9323-5329-0410-9bdc-e9ce6186880e
