The debug info in the dwp file needs to refer to the .debug_line and
.debug_line_str sections in the main binary.
This fixes dump_syms not generating LINE records for dwp in split dwarf.
Bug: chromium:1448979
Change-Id: I71923f12cea72caae081c1406e2cbca55e95859e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4576346
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
It fixes following two problems:
1. When we have skeleton compilation unit (DW_TAG_skeleton_unit) in a
binary file refers to the complete unit in a split dwarf file
(.dwo/.dwp file), we should use the split dwarf file's path in warning
reporting. Right now, it uses the original file (binary file) path in
warning report, which is incorrect.
For example, if we have chrome.debug which is the binary with skeleton
debug info and chrome.dwp which is the complete debug info and the debug
info in chrome.dwp has some incorrect reference, it will warn on
chrome.debug rather than chrome.dwp
2. When split dwarf is enabled, the global inline_origin_map will likely
encounter key collision because the offsets as keys are now relative to
each CU's offset which is relative to .debug_info section. Also
offsets from different files might collide.
This change makes a inline_origin_map for each debug file and use
offsets only relative to .debug_info section as keys.
Bug: b/280290608
Change-Id: If70e2e1bfcbeeeef2d425c918796d351a0e9ab3b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4544694
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When built with -gmlt, .dSYMs are (by design) missing the
`DW_AT_linkage_name` which Breakpad uses to fill out the
(name-mangled) function names.
Thankfully, the .dSYM contains both the old-school LC_SYMTAB command
containing the STABS-format symbols (which include the fully-qualified
C++ symbol names we want, but no actual compilation unit data), as
well as the LC_SEGMENT_64 containing the __DWARF segment with the
minimal -gmlt debug information (which excludes the name-mangled C++
symbols).
Unfortunately, since the .dSYM's STABS does not define compilation
units, the usual path in `StabsReader` ignores all the fully-qualified
C++ symbol names for the functions:
bd9d94c708/src/common/stabs_reader.cc (100)
Fortunately, when built for macOS platforms (`HAVE_MACH_O_NLIST_H`),
`StabsReader` supports storing all the STABS-format symbols as
`Extern`s, regardless of whether or not they're in a compilation unit:
bd9d94c708/src/common/stabs_reader.cc (119)
Currently, when there's both a `Function` and an `Extern` with the same address, `Module` discards the `Extern`:
bd9d94c708/src/common/module.cc (161)
This CL adds a new `-x` option to the Mac `dump_syms` which prefers
the Extern function name if there's a mismatch.
Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=883
Change-Id: I0d32adc64fbf567600b0a5ca63c71c422b7f0f8c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4453650
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
`NXFindBestFatArch` is deprecated in macOS 13. We use this when an
architecture is passed in via the `-a` flag. Unfortunately, neither
of the potential replacements can help with this use case:
- `macho_for_each_slice` as suggested in a reply to FB11955188 just
enumerates slices, without the logic for inexact matches (for example,
x86_64h -> x86_64 or arm64e -> arm64).
- `macho_best_slice` as recommended by the deprecation notice only
supports finding a suitable slice to run on the local machine.
We could adapt the logic in `NXFindBestFatArch` but it gets quite
complex for some architectures. Instead, this change adapts the
`NXFindBestFatArch` polyfill used in `dump_syms_mac` for Linux, which
returns an exact match if possible, and the first slice that matches
the requested CPU type otherwise. I think this is probably Good
Enough for most cases; if not, we can try porting the x86_64 and ARM
logic and falling back to this for the rest.
Change-Id: I3b269dab7246eced768cecd994e915debd95721a
Bug: chromium:14206541420654
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4335477
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, dump_syms always used the basename of the on-disk file as
the Breakpad module name and required that the on-disk filename of the dSYM and binary file match, or it would exit with an error.
Build automation often uses filenames unrelated to the Breakpad module
name, so this CL adds a new optional "-n MODULE" argument to Mac
dump_syms that allows passing in the Breakpad module name from outside.
In this case, the basename of the on-disk file(s) is ignored and
no longer required to match.
Change-Id: Ic38e8cf762c79bce61d289b397293eff6c0039ce
Bug: b/273531493
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4338857
Reviewed-by: Robert Sesek <rsesek@chromium.org>
It's deprecated in macOS 13/iOS 16, so this is an incremental step towards using newly introduced APIs for those OSes.
Since the description field is no longer available in the new
mach-o/util.h API, stop using it, especially since architecture name is
sufficiently informative.
Bug: chromium:1420654
Change-Id: If2cec4f1fc88d13a71f011822bff61f173486b68
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4322265
Reviewed-by: Mark Mentovai <mark@chromium.org>
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>
On macOS 13 x86_64 machines, NXFindBestFatArch does not correctly find
arm64e slices. This is filed as FB11955188.
I was hoping manually masking the subtype with CPU_SUBTYPE_MASK would
be sufficient to work around but no luck. So let's just fall through
to doing an exact* match if NXFindBestFatArch fails.
* "Exact" meaning with CPU_SUBTYPE_MASK now masked off. But
libmacho/arch.c calls that exact too, so I'm just going to go with it.
Bug: 1400770
Change-Id: Id497946d3c719285c5d7508e589e4a466da1ceca
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4178621
Reviewed-by: Mark Mentovai <mark@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>
- Resets `selected_object_file_` when a new file is read. This was a dangling pointer previously.
- When `-a` is provided, ensures that both parts of a split module use
the given architecture.
Bug: None
Change-Id: I581d41b0eee4ec2b0d598fb80b9065e7ebde0e0d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3788222
Reviewed-by: Mark Mentovai <mark@chromium.org>
https://crrev.com/c/3327644 introduced the ability for dump_syms to
operate on in memory data, which has the consequence of not going
through the same input validation as the dump_syms cli tool. In certain
cases, it is possible that architecture info can't be reliably
determined, e.g. new architectures that breakpad is unware of. In that
case, dump_syms should avoid crashing when calling ReadSymbolData and
return false instead.
Change-Id: Ie9acdf811300084f1d5916f4778754f8abca10e0
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3572251
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
In trying to create a backend service that can process both ELF and
Mach-O binaries, I found that symbol collisions occur when trying to
link different implementations of FileID. This change puts the
different implementations into separate namespaces to avoid the
collision.
Change-Id: I15aabb222803f2ffbda15ed13e66793bae32ddce
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3421417
Reviewed-by: Mark Mentovai <mark@chromium.org>
dump_syms assumes it is operating on a file and can access a compliant
file system. This change allows dump_syms to operate on the contents of
a file that has already been read into memory. This is useful in a
server context where the file does not exist on the local file system.
Change-Id: Id63f115c2df287083d548dadd5ac487f97bde057
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3327644
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change makes sure dump_syms process DW_TAG_inlined_subroutine only when -d flag is given, which save memory and time when -d is not given. Before this, it always processes DW_TAG_inlined_subroutine and -d determines whether or not to emit INLINE records.
Bug: chromium:1250351, chromium:1246974
Change-Id: I54725ba1e513cafe17268ca389ff8acc9c11b25e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3166674
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The size of symbol file for chrome binary increased from 577 MB to
1205 MB. There are 7,453,748 INLINE records and 1,268,493 INLINE_ORIGIN
records.
Bug: 1190878
Change-Id: I802ec1b4574c14f74ff80d0f69daf3c81085778a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2915828
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The auto-detection of the UUID was missing the extra "0" added for
compatibility reasons. The native upload also was sending malformed
HTTP.
Change-Id: I8c261fc525f0f0086f269f2dee02941dd55488cb
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2739320
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
There's no need to pass in debug ID to symupload for native symbol
uploads, as breakpad can extra the ID itself for dsym and macho types.
Change-Id: Ib0b7703eac85bc84fe1f095e678d75b347bd872a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2724731
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a big change. dwarf5 range lists are quite a bit more complicated
than dwarf 4 range lists, both in the contextual information required, and
in their own representation and interpretation.
The big design choice here is how to pass the CU information all the
way down to the reader. I chose a structure, because otherwise the
parameter list gets very long and error prone (and has to be passed
down several levels). This structure could be made a parto of the CU
context itself, or the range handler, so it wouldn't have to be
separately assembled at range-list read time, but both of those
solutions get even more invasive, and harder to follow.
I've tried to figure out how to break this into smaller changes, but it
affects nearly everything that has to do with a compilation unit's
own addresses and when decisions must be made about how to read them.
Dependency injection will do that to you.
It does add tests for range list reading, which did not exist before.
Change-Id: I923b9a2c3379a0f52609bc05310097de5cbb7227
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446635
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This reverts commit 2b936b06c1.
After getting deep into the dwarf5 range reader, I realized that this
should be done a somewhat different way. So reverting in favor or
a better design, coming in a few minutes.
Change-Id: Ie0b2846e70b3df1e637831e96ea69fe093f4e712
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446011
Reviewed-by: Mark Mentovai <mark@chromium.org>
Dwarf5 introduces a new .debug_rngslist section, to take the place
of the Dwarf4 .debug_ranges. However, the dwarf version is CU-based,
and not file-based, so there can be both sections, and which section
the CU needs isn't known until the dwarf parser encounters either
DW_AT_ranges (dwarf 4 and lower) or DW_AT_rnglists_base (dwarf 5).
This change refactors the code around range lists and range list
readers to defer the decision of what section to parse until
the relevant attribute is found. It moves the range list section
reader from the range-list handler itself (which doesn't know which
section it will use) to the CU context, and then lets the handler
know when it encounters DW_AT_ranges.
I will add a reader for the new dwarf5 section, along with the code to
interpret the new section, and its forms and such in a subsequent patch.
Change-Id: Ie92e4c9daa3f0acb98d7ef74f6b9c2065db849b1
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2433684
Reviewed-by: Mark Mentovai <mark@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>
A .dSYM may validly contain a __DWARF segment without any __debug_info
section. This can occur for Chromium Framework in a component build of
Chromium, because in that case, all of the code is in other libraries
that Chromium Framework depends on.
This was previously tested by an assertion, but the assertion did not
trigger in NDEBUG (release) builds. In NDEBUG builds, this condition
would lead to an out-of-bounds read, detected by AddressSanitizer.
Instead of an assertion, the check is now always done at runtime.
Instead of being fatal, it's now just a warning, because it's been
established that __DWARF without __debug_info can occur.
(In the Chromium case, it remains pointless to run dump_syms via the
"chrome_dump_syms" target on a component build, as it'll only attempt to
symbolize Chromium Framework, and not any of the libraries that Chromium
Framework depends on that actually contain the code.)
Bug: chromium:991206
Change-Id: I6c9c75f0be7901813e3eaae54aff38c1afe73ca9
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1741610
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This enables the DWARF reader to properly parse DW_AT_ranges attributes
in compilation units and functions. Code covered by a function is now
represented by a vector of ranges instead of a single contiguous range
and DW_AT_ranges entries are used to populate it. All the code and tests
that assumed functions to be contiguous entities has been updated to
reflect the change. DW_AT_ranges attributes found in compilation units
are parsed but no data is generated for them as it is not currently needed.
BUG=754
Change-Id: I310391b525aaba0dd329f1e3187486f2e0c6d442
Reviewed-on: https://chromium-review.googlesource.com/1124721
Reviewed-by: Ted Mielczarek <ted.mielczarek@gmail.com>
This hides the need to provide mutable C strings, and unifies
existing basename calls and variations in a single location.
Change-Id: Idfb449c47b1421f1a751efc3d7404f15f8b369ca
Reviewed-on: https://chromium-review.googlesource.com/725731
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Patch provided by Thomas Schweitzer.
BUG=
Change-Id: I1721db8cab7774b433ff6703a0ddc1eab6620c0b
Reviewed-on: https://chromium-review.googlesource.com/379898
Reviewed-by: Mark Mentovai <mark@chromium.org>
This added debug fission support.
It tries to find the dwp file from the debug dir /usr/lib/debug/*/debug
and read symbols from them.
Most of this patch comes from
https://critique.corp.google.com/#review/52048295
and some fixes after that.
The elf_reader.cc comes from TOT google code. I just
removed some google dependency.
Current problems from this patch
1: Some type mismatch: from uint8_t * to char *.
2: Some hack to find the .dwp file. (replace .debug with .dwp)
BUG=chromium:604440
R=dehao@google.com, ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1884283002 .
It is often helpful to check if a particular symbol file dumped by
dump_syms actually matches a version of a binary file we have. The
symbol output contains an ID which can be used to see if it matches
the binary file. Unfortunately, this ID is internally calculated
and not a standard hash of the binary file. Being able to output the
header information only will allow users to determine whether their
symbol file is up to date or not.
R=jochen@chromium.org
BUG=561447
Review URL: https://codereview.chromium.org/1864823002 .
Patch from David Yen <dyen@chromium.org>.
Newer gcc versions default to -Werror=narrowing when using newer C++
standards (which we do). This causes issues when we try to stuff a
value like 0xea into a char -- the value is out of range for signed
char bytes. That's when gcc throws an error:
.../bytereader_unittest.cc: In member function 'virtual void Reader_DW_EH_PE_absptr4_Test::TestBody()':
.../bytereader_unittest.cc:400:55: error: narrowing conversion of '234' from 'int' to 'char' inside { } [-Wnarrowing]
BUG=chromium:579384
TEST=`make check` passes
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1605153004 .
We're working on building our Firefox Mac builds as a Linux cross-compile
(https://bugzilla.mozilla.org/show_bug.cgi?id=921040) and we need symbol
dumping to work. This change ports the Mac dump_syms tool to build and work
on Linux. I've tested it and it produces identical output to running the
tool on Mac.
The bulk of the work here was converting src/common/mac/dump_syms.mm and
src/tools/mac/dump_syms/dump_syms_tool.mm from ObjC++ to C++ and removing
their use of Foundation classes in favor of standard C/C++.
This won't compile out-of-the-box on Linux, it requires some Mac system
headers that are not included in this patch. I have those tentatively in
a separate patch to land in Gecko
(http://hg.mozilla.org/users/tmielczarek_mozilla.com/mc/rev/5fb8da23c83c),
but I wasn't sure if you'd be interested in having them in the Breakpad tree.
We could almost certainly pare down the set of headers included there, I
didn't spend too much time trying to minimize them (we primarily just need
the Mach-O structs and a few associated bits).
I just realized that this patch is missing updating the XCode project files
(ugh). I'll fix that up in a bit.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=543111
Review URL: https://codereview.chromium.org/1340543002 .
