| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Bug: chromium:940823, chromium:946404
Change-Id: Ib8af7f0845b0488f36cd1b91326aba11bf283b0a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1546779
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>
|
| |
|
|
|
|
|
|
|
| |
The %ld expects a long signed integer, but we're passing in a size_t.
Use %zu which is an unsigned size_t type.
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1951603002 .
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
| |
|
|
|
|
|
| |
Reviewed at https://breakpad.appspot.com/7834002/#ps340001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1453 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Because CPU_TYPE_ARM is not defined on Mac OSX 10.4, I have to redefine the
variable to the correct value.
Review URL: http://breakpad.appspot.com/310004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@867 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix up some broken mac projects.
Consolidate project settings in xcconfig files.
http://breakpad.appspot.com/130001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@627 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
|
