aboutsummaryrefslogtreecommitdiff
path: root/src/common/mac/macho_reader.cc
Commit message (Collapse)AuthorAgeFilesLines
* fix pointer style to match the style guideMike Frysinger2020-07-151-19/+19
| | | | | | | | | | 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>
* mac dump_syms: remove unused vars to fix -Werror build failuresMike Frysinger2019-04-051-1/+0
| | | | | | | 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>
* mac dump_syms: Support .dSYMs > 4GB (partially)Mark Mentovai2019-03-281-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* macho: fix printf type mismatchesMike Frysinger2016-05-041-3/+3
| | | | | | | | | 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 .
* [mac] Teach dump_syms to handle additional zerofill sectionsPavel Labath2015-09-301-1/+3
| | | | | | | | | | | | | | 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>.
* Support object files larger than 2**32.erikchen@chromium.org2015-04-221-15/+17
| | | | | | | Reviewed at https://breakpad.appspot.com/7834002/#ps340001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1453 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Support symbol dumping for ARMV8 iOS apps.qsr@chromium.org2013-10-151-0/+5
| | | | | | | | | | | | | | | 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
* Handling reading arm executable.qsr@chromium.org2011-10-121-0/+6
| | | | | | | | 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
* Clean up build for 64 bit.dmaclach2010-07-191-1/+1
| | | | | | | | | | | 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
* Breakpad Mac symbol dumper: Add new Mach-O reader class.ted.mielczarek2010-06-251-0/+524
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