Partitioned libraries generated with lld and llvm-objcopy currently
contain a superset of debug information, beyond what applies to the
library itself. This is because objcopy cannot split up debug
information by partition - instead, it places a copy of all debug
information into each partition.
In lieu of potential future support for lld or objcopy becoming able to
split up debug information, let dump_syms do the next best thing:
- Find the address ranges of all PT_LOAD segments in the lib.
- Supply these to the Module being generated.
- Filter additions to the Module based on these ranges.
Bug: 990190
Change-Id: Ib5f279f42e3f6ea79eed9665efbcc23c3c5d25dc
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1884699
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The Breakpad and Crashpad clients will use an object's DT_SONAME as
the name for a module if it exists. Previously, linux dump_syms would
assume the basename of an input elf file matches that value, causing
symbol lookups to fail if they were mismatched. This patch updates
dump_syms to use DT_SONAME as the module name, if present.
Bug: 1016924
Change-Id: I5eff0cf06c703841df3fb552cb5a8e1e50a20c64
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1876763
Reviewed-by: Mike Frysinger <vapier@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>
Since target_ptr is of type uint16_t* already, we don't need to scale
the byte count as the language does that for us. If it were void*, we
would need this code, but it's not.
In practice it's probably not a big deal due to how we preallocated
memory: when converting UTF8->UTF16, we'd reserve the same number of
code units, and UTF8 takes more code units per codepoint than UTF16,
so the UTF16 vector is always oversized.
When converting UTF32->UTF16, we also reserve the same number of
code units, but since one UTF32 code unit could require two UTF16
code units (for U+10000 codepoints and higher), we would probably
corrupt memory in the process. The APIs in this module don't seem
to take into account that range in general, so for now I'm only
fixing the memory corruption.
Bug: google-breakpad:768
Change-Id: Ibfaea4e866733ff8d99b505e72c500bd40d11a74
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1732888
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Only 64-bit PEs supported.
- Re-add some scripts that were missed in initial move of code.
- Change msdia120.dll dependency to msdia140.dll.
- Add tests for Intel, AMD, and NVidia Microsoft Symbol Stores.
- Windows symbol converter now attempts to fall back to PE-only metadata
when it fails to locate a PDB.
- Remove the 'binary' folder under converter_exe. Need to think more
about how a deployment should look and what tool(s) to use in creating
one.
Change-Id: I52e42cbe5e759874a25114c2483e8b50d73fdf77
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1670098
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Add a #define to testing.gyp to avoid warnings about TR1 deprecation.
- PESourceLineWriter now reads debug_file from CodeView record instead
of using code_file value.
- Updated PE-only MD reading unit test.
Change-Id: Ib4e6201df3e3fd651e160f310584b5a67b16c842
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1668347
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Rename two files from '.cpp' to '.cc' and insert missing comma in
between lines in source files list.
Change-Id: I169a738b565f52292cb0292b34c4397e9dc05370
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1666351
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Implement in common_windows_lib-- added class "PESourceLineWriter".
- Add command-line switch to tell dump_syms to use PESourceLineWriter.
Symbol data created this way will contain information to correlate the
module with ones found in minidumps, along with frame info that allows
much higher quality stack-walking in those minidumps.
- Significant refactor of PDBSourceLineWriter-- all code concerned with
extracting metadata from PE files has been moved into utility
functions. This is to allow sharing of this functionality with newly-
added PESourceLineWriter.
- Added a unit test to dump_syms for the PE-only scenario.
Change-Id: If0855f05d424d32d23f484995be5f34232179a37
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1525325
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Chrome's test runner on Linux installs its own StackDumpSignalHandler
which swallows signals and doesn't re-raise them. This is sloppy, but
apparently there are reasons (https://crbug.com/551681). For
breakpad_unittests, it causes problems where a test process expects (via
waitpid()) to observe a child crash. Deal with those cases by
explicitly restoring the default signal handler.
In another case, Chrome's test runner seems to have been arriving at the
conclusion that it was to expect output from a child. Transitioning from
exit() to _exit() fixes this problem, and it's not necessarily a bad
idea to do this in post-fork() children without an execve() anyway.
Bug: chromium:949098
Change-Id: I5a6af0c2a09cd8eac9998358f6d5ea665288236f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1575670
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>
When building on an old system with outdated headers, this define
might not be available. Add a fallback to our existing elf header.
Bug: google-breakpad:790
Change-Id: I4dfe7a5cebd414cca3582a1a9cfc983503d5a779
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1507073
Reviewed-by: Mark Mentovai <mark@chromium.org>
TYPED_TEST_CASE is deprecated in modern googletest.
BUG=chromium:936654
Change-Id: I08004ffbb26089ebe17302934ed6d3268220d151
Reviewed-on: https://chromium-review.googlesource.com/c/1493423
Reviewed-by: Mark Mentovai <mark@chromium.org>
Also remove ranges_handler_ which is unused.
Change-Id: I771bf4b5fc4410f0406bf26e1e405905b55389ab
Reviewed-on: https://chromium-review.googlesource.com/1180587
Reviewed-by: Mark Mentovai <mark@chromium.org>
The high_pc is an address and has already been read from .debug_addr
before being passed into FuncHandler::ProcessAttributeUnsigned.
Bug:870908
Change-Id: I950098e360b5193f26bf767b8fa0a5f9d59e66ce
Reviewed-on: https://chromium-review.googlesource.com/1178760
Reviewed-by: Mark Mentovai <mark@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>
When DW_AT_MIPS_linkage_name doesn't demangle, breakpad currently throws
the symbol completely, but in some cases, there is no DW_AT_name or
DW_AT_abstract_origin to figure out a name, and the raw value from
DW_AT_MIPS_linkage_name is still better than nothing. Fall back to that
in when there is nothing else.
R=ted@mielczarek.org
Change-Id: I5cc7580244f2b99f5f1f279d09b904031cae1a37
Reviewed-on: https://chromium-review.googlesource.com/1082176
Reviewed-by: Ted Mielczarek <ted.mielczarek@gmail.com>
endl flushes output after each line. Using "\n" instead significantly improves
I/O efficiency.
Change-Id: If6a5549fc3613ca3a7c9a71838ec36c5b7a20580
Reviewed-on: https://chromium-review.googlesource.com/1077626
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Adds asm/ and machine/ directories to src/common/android/include. This
is necessary because some required files for MIPS were removed in newer
Android NDK versions, which broke Breakpad compilation.
Bug: 771171
Change-Id: Ie6a079b6b8130b549ebc6d0bc4aef0e47e7bd6c2
Reviewed-on: https://chromium-review.googlesource.com/835282
Reviewed-by: Mark Mentovai <mark@chromium.org>
Breakpad shouldn't be hacking up headers for LSS. This was eventually
fixed in LSS directly in https://codereview.chromium.org/1248033002, so
we can drop this hack on our side.
Change-Id: Iff29efe7f6af40835e0aab1f6ac3fd8d167045ef
Reviewed-on: https://chromium-review.googlesource.com/843124
Reviewed-by: Mark Seaborn <mseaborn@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Updates dump_syms to write the optional 'm' first field in FUNCTION and
PUBLIC records to indicate that the address corresponds to more than one
symbol.
Bug: google-breakpad:751
Change-Id: I850b0122324ed5f9ec747aa92ba354a3126a7ef9
Reviewed-on: https://chromium-review.googlesource.com/820711
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds an optional 'm' as the first field in FUNCTION and PUBLIC records
to indicate that the address corresponds to more than one symbol.
Controls this by a command line flag for now to give symbol file users
a chance to update.
Also reduces the number of IDiaSymbols retained in memory to one per
address. This reduces memory consumption by 8% when processing
chrome.dll.pdb.
Updates the processor to parse the new optional field.
Bug: google-breakpad:751
Change-Id: I6503edaf057312d21a1d63d9c84e5a4fa019dc46
Reviewed-on: https://chromium-review.googlesource.com/773418
Reviewed-by: Mark Mentovai <mark@chromium.org>
Consistently output the "least" symbol by decorated name when
multiple symbols share an address.
Testing with chrome.dll.pdb the diffs between the new and old output
look sensible, and this is actually ~20% faster than the existing
implementation.
Bug: 749
Change-Id: Ie638559b63f0eb2dcb80b1ebb579228d62c63bb2
Reviewed-on: https://chromium-review.googlesource.com/758885
Reviewed-by: Mark Mentovai <mark@chromium.org>
This enables repeatedly setting a value based on index, which avoids a
linear scan of the entry table after the first SetKeyValue().
Bug: chromium:598854
Change-Id: I9964670a09dcd8ff76180d031a373f20990bf4d8
Reviewed-on: https://chromium-review.googlesource.com/757579
Reviewed-by: Mark Mentovai <mark@chromium.org>
The lld linker has native support for creating packed relocation
sections, and as a result we can expect files with these sections to
have symbols.
Bug: chromium:742655
Change-Id: I48a50bff041146f51b3a8b730d7a778f832787f6
Reviewed-on: https://chromium-review.googlesource.com/754239
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This relands fd0a0d2b7a which was reverted
in 5dad29423e, with a fix for guarding
kMaxSuffixLength which only used in assert()s with macros which breaks
chromium.mac/ios-device.
Change-Id: I5ee21b7f290517d6e7a0ef90b693b97f92392549
Reviewed-on: https://chromium-review.googlesource.com/751922
Reviewed-by: Mark Mentovai <mark@chromium.org>
This silences a warning in newer versions of clang that complains
about "register" being a deprecated keyword.
Bug: chromium:780692
Change-Id: If354b9b18421e3e910849b385c44207e0ce02590
Reviewed-on: https://chromium-review.googlesource.com/750362
Reviewed-by: Mark Mentovai <mark@chromium.org>
C++ doesn't allow skipping initialization with a goto. This means that
this code is illegal:
void func(bool b) {
if(b) goto END;
int value = 0; //error C2362 with /permissive-
//... value used here
END:
return;
}
Adding an extra scope makes the code legal. This problem is only
detected with /permissive- but now that compiling with this
switch is practical we might as well stay /permissive- clean:
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/
Note that compiling /permissive- clean only works with the 10.0.16299.0
SDK which currently has other issues...
Bug: 773476
Change-Id: I54e64aaef46d70a817cf7da272f76d9ae5f6a6f7
Reviewed-on: https://chromium-review.googlesource.com/740287
Reviewed-by: Mark Mentovai <mark@chromium.org>
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>
memory.h shadows a system header which normally isn't a problem
because of the include paths in Breakpad, but the Firefox build
system winds up with src/common in the include path so we've had
a workaround for this for years. Renaming the file lets us get
rid of that workaround and shouldn't hurt anything.
Change-Id: I3b7c4239dc77f3b2b7cf2b572a0cad88cd7e8522
Reviewed-on: https://chromium-review.googlesource.com/723261
Reviewed-by: Mark Mentovai <mark@chromium.org>
When using traditional headers, sys/types.h is needed to define __u64
for sys/user.h. Previously, we thought this would be provided by
stdint.h, but it is not.
Change-Id: I0e648712f4ef1e303104a5264d3d2d0b218f5d45
Reviewed-on: https://chromium-review.googlesource.com/705267
Reviewed-by: Mark Mentovai <mark@chromium.org>
This was lost in afa9c52715, but it turns out that it’s still
necessary.
Bug: google-breakpad:733
Change-Id: I4e0e4e4d2e80c22df1ff6b82e471905773c940a3
Reviewed-on: https://chromium-review.googlesource.com/675732
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
1. testing.gyp is a gyp file, not a gypi file. It is only referenced in
“dependencies” sections. The gypi extension is used for files that are
included by an “includes” section.
2. Update paths in testing.gyp to reflect the real locations of
googletest and googlemock following their merge into a single
repository.
Change-Id: If9c356d93aa5ffda54af46fbed648baa2274dac6
Reviewed-on: https://chromium-review.googlesource.com/673404
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Chrome uses API 16 for 32-bit builds and API 21 for 64-bit builds. The
NDK’s <link.h> provides r_debug and link_map structure definitions only
at API 21 and above. Breakpad used a custom <link.h> to define these
structures only during 64-bit builds, which worked for Chrome’s
purposes. However, other consumers may wish to build Breakpad at
arbitrary API levels without regard to bitness. This alters Breakpad’s
custom <link.h> to correctly check the NDK API level rather than target
CPU bitness.
Likewise for <sys/user.h> on 32-bit x86, which provided a typedef for
user_fpxregs_struct to user_fxsr_struct. API 21 and above, as well as
the unified headers at any API level, always name the structure
user_fpxregs_struct.
Definitions for 64-bit ARM’s user_regs_struct and user_fpsimd_struct
have been removed from Breakpad’s copy of <sys/user.h>. The header
claims that these fallback definitions are only necessary with NDK r10,
which should no longer be in use even by Chromium, which now uses NDK
r12b. This removes the Chromium-specific ANDROID_NDK_MAJOR_VERSION macro
from use entirely.
Fixes https://stackoverflow.com/questions/44141159/ and b/65630828.
Bug: google-breakpad:733
Change-Id: I5841906297cd15b15ce48b73fd8332fd40afc9a0
Reviewed-on: https://chromium-review.googlesource.com/665740
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Breakpad’s DWARF line table reader only understood line tables at the
level of DWARF 2. This wasn’t a problem because LLVM only produced line
tables at this level, even when generating DWARF 4. But LLVM would like
to output DWARF 4 line tables when generating DWARF 4, and Breakpad
needs to understand this format. (Meanwhile, it seems that GCC has used
DWARF 4 line tables with DWARF 4 output since 4.5.0, 2010-04-14.)
DWARF 3 line tables are fully compatible with DWARF 2 (assuming that
nothing needs “prologue end,” “epilogue begin,” or “isa”, and opcodes
related to these fields are properly skipped). DWARF 4 changes the line
number program header slightly to include a “maximum operations per
instruction” field. This field must be recognized, but can safely be
ignored (and assumed to be always 1) if VLIW architectures are not
supported (they aren’t). DWARF 4 also introduces a “discriminator”,
whose opcode can also be skipped if these values are not needed (they
shouldn’t be).
This recognizes the “maximum operations per instruction” field when
processing DWARF 4 line tables, but asserts that its value is 1 and
otherwise ignores it.
This is not compatible with VLIW architectures that set this field to a
value other than 1. Such architectures are irrelevant to Breakpad, and
mainline GCC and the proposed LLVM patch always set this field to 1.
There are other things that could be extracted from DWARF 3 and 4 line
tables that aren’t currently extracted (although these are currently
irrelevant to Breakpad too).
Bug: google-breakpad:745
Change-Id: I5bf9c0b1aa654849c9cce64e60682447d10be8ba
Reviewed-on: https://chromium-review.googlesource.com/663441
Reviewed-by: Mike Frysinger <vapier@chromium.org>
It is legal for an ELF to contain multiple PT_NOTEs, and that is in
fact what lld's output looks like.
Testing: "make check" and breakpad_unittests when patched into
chromium.
Bug: chromium:716484
Change-Id: I01d3f8679961e2cb7e789d4007de8914c6af357d
Reviewed-on: https://chromium-review.googlesource.com/513512
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Ted Mielczarek <ted@mielczarek.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
x86_64h has a different cpusubtype from x86_64. The h is for Haswell.
BUG=
Change-Id: Icf884e5699fe120c12d13aa57cd62db5b69a2ce6
Reviewed-on: https://chromium-review.googlesource.com/457171
Reviewed-by: Ted Mielczarek <ted@mielczarek.org>
The layout of Elf32_Nhdr and Elf64_Nhdr is the same, so remove
templating and code that extracts the elfclass from the ELF file.
Testing: "make check" and breakpad_unittests when patched into
chromium.
Bug: chromium:716484
Change-Id: I41442cfff48afc6ae1a5b604d22b67550a910376
Reviewed-on: https://chromium-review.googlesource.com/514450
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Change a9fca58 made use of the O_CLOEXEC flag, which is not supported on
older Linux kernels. This change makes the use contingent on kernel
support.
Testing: I manually compiled breakpad on CentOS 5.8 running kernel
2.6.18-308.8.2.el5.centos.plusxen.
Bug: 730
Change-Id: I21dff928cfba3c156a56708913f65a0c7b5396a6
Reviewed-on: https://chromium-review.googlesource.com/498528
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This patch ensures that two crashes taken within the same second have
different minidump names. The random characters used in the minidump
filename are now read from /dev/urandom where possible or generated via
arc4random(). If neither is available we fall back to regular rand() but
mixing the address of an object to the current time when generating the
random seed to make it slightly less predictable.
BUG=681
Change-Id: I2e97454859ed386e199b2628d6b7e87e16481b75
Reviewed-on: https://chromium-review.googlesource.com/445784
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Because many apps still support iOS 8, they were defaulting to
deprecated NSURLConnection even if the code ran on iOS 10.
NSURLConnection requires a run loop and hence the code did not
always upload if the queue ran on a thread without a Run Loop.
This should improve break pad uploads
BUG=
Change-Id: I7bff80ea977fd1ab13c8812ed933ef842dab417f
Reviewed-on: https://chromium-review.googlesource.com/451880
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Clang complains about bad format strings (DWORD is an unsigned long, not
unsigned int) and signed/unsigned comparison.
This change is necessary for https://codereview.chromium.org/2712423002/
BUG=245456
Change-Id: I58da92d43d90ac535c165fca346ee6866dfce22e
Reviewed-on: https://chromium-review.googlesource.com/448037
Reviewed-by: Mark Mentovai <mark@chromium.org>
This handles a case encountered in ntdll.dll symbols for Windows 7,
where a PUBLIC would be emitted only for the entry point to the
function. The body of the function, however, is split in a PGO-ish
fashion to another remote location in the binary. Because of this, there
were large gaps in the RVA space that would be attributed to the "last"
function that happened to have an entry point before the gap. In
practice, something like this:
0x100 Func1
0x110 Func2
0x120 Func3
0x130 Func4
...
0x800 LaterFuncs
The bodies of Func1/2/3 tend to be implemented as a fast-path check,
followed by a jmp to somewhere in the range between 0x130 and 0x800.
Because no symbols are emitted for this range, everything is attributed
to Func4, causing crash misattribution.
In this CL, the change is: after emitting the entry point symbol, also
walk in the original OMAP entries through the untranslated binary, and
for each block until we resolve to a new symbol (via the same mechanism
as we found the entry point) emit another PUBLIC indicating that there's
another block that belongs to that symbol. This effectively breaks up
the "0x130 - 0x800" range above.
R=mark@chromium.org
BUG=chromium:678874
Change-Id: Ib3741abab2e7158c81e3e34bca4340ce4d3153a1
Reviewed-on: https://chromium-review.googlesource.com/446717
Reviewed-by: Mark Mentovai <mark@chromium.org>
This avoids compile time errors:
In file included from ./src/testing/googletest/include/gtest/gtest.h:1874:0,
from ./src/breakpad_googletest_includes.h:33,
from src/common/mac/macho_reader_unittest.cc:39:
src/common/mac/macho_reader_unittest.cc: In member function 'virtual void LoadCommand_SegmentBE32_Test::TestBody()':
./src/testing/googletest/include/gtest/internal/gtest-internal.h:133:55: error:
converting 'false' to pointer type for argument 1 of 'char testing::internal::IsNullLiteralHelper(testing::internal::Secret*)' [-Werror=conversion-null]
(sizeof(::testing::internal::IsNullLiteralHelper(x)) == 1)
^
...
src/common/mac/macho_reader_unittest.cc:1117:3: note: in expansion of macro 'EXPECT_EQ'
EXPECT_EQ(false, actual_segment.bits_64);
Change-Id: I0cf88160dbe17b0feebed3c91ad65491b81023fd
Reviewed-on: https://chromium-review.googlesource.com/439004
Reviewed-by: Mark Mentovai <mark@chromium.org>
The Windows build has rotted a bit with the gtest/gmock updates.
Update all of the paths to fix things up again.
Change-Id: Id67ce76abfd331c0543aa4bd1138e9cc13a18c75
Reviewed-on: https://chromium-review.googlesource.com/441584
Reviewed-by: Mark Mentovai <mark@chromium.org>
code.google.com is obsolete.
Fix all broken markdown links while at it.
Change-Id: I6a337bf4b84eacd5f5c749a4ee61331553279009
Reviewed-on: https://chromium-review.googlesource.com/411800
Reviewed-by: Mike Frysinger <vapier@chromium.org>
For more details take a look at common/using_std_string.h
BUG=
Change-Id: Ifebfc57f691ef3a3bef8cfed7106c567985edffc
Reviewed-on: https://chromium-review.googlesource.com/399738
Reviewed-by: Mark Mentovai <mark@chromium.org>
CIE looks like it's been emitted by clang since ~May 2015 [1]. This
means that we didn't have any CFI because this parse aborted, which
meant that all stack walks reverted to stack scanning. Allow expected
values for address size and segment descriptor size through so that
dump_syms can generate at least somewhat reasonable data.
[1]: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150518/277292.htmlR=mark@chromium.org
BUG=chromium:627529
Change-Id: I6dc92f51c4afd25c2adff92c09ccb8bb03bf9112
Reviewed-on: https://chromium-review.googlesource.com/406012
Reviewed-by: Mark Mentovai <mark@chromium.org>
Found by PVS-Studio!
BUG=chromium:660198
Change-Id: I2605de2b1499f85c6e01d19e87e9eeb6af8486f3
Reviewed-on: https://chromium-review.googlesource.com/404552
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The Rust compiler uses GCC C++ name mangling, but it has another layer of
encoding so abi::cxa_demangle doesn't produce great results. This patch
changes dump_syms to dump unmangled names by default so that consumers can
demangle them after-the-fact.
It also adds a tiny bit of support for linking against a Rust library I wrote
that can demangle Rust symbols nicely:
https://github.com/luser/rust-demangle-capi
BUG=
Change-Id: I63a425035ebb7ac516f067fed2aa782849ea9604
Reviewed-on: https://chromium-review.googlesource.com/402308
Reviewed-by: Mark Mentovai <mark@chromium.org>
The DWARF data for Swift code has a top-level DW_TAG_module DIE as the
child of the DW_TAG_compile_unit DIE and the parent of the
DW_TAG_subprogram DIEs that dump_syms uses to locate functions.
dump_syms needs to process DW_TAG_module DIEs as introducing nested
scopes to make it work with Swift.
This also reworks demangling to be language-specific, so that the C++
demangler isn't invoked when processing Swift code. The DWARF data for
Swift code presents its mangled names in the same form as used for C++
(DW_AT_MIPS_linkage_name or DW_AT_linkage_name) but the mangling is
Swift-specific (beginning with _T instead of _Z). There is no
programmatic interface to a Swift name demangler as an analogue to C++'s
__cxa_demangle(), so mangled Swift names are exposed as-is. Xcode's
"xcrun swift-demangle" can be used to post-process these mangled Swift
names on macOS.
Support for mangled names presented in a DW_AT_linkage_name attribute,
as used by DWARF 4, is added. This supersedes the earlier use of
DW_AT_MIPS_linkage_name.
BUG=google-breakpad:702,google-breakpad:715
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/2147523005 .
Patch provided by Thomas Schweitzer.
BUG=
Change-Id: I1721db8cab7774b433ff6703a0ddc1eab6620c0b
Reviewed-on: https://chromium-review.googlesource.com/379898
Reviewed-by: Mark Mentovai <mark@chromium.org>
For more details take a look at common/using_std_string.h
BUG=
Change-Id: I11f1ce697be23e13f12ea8f0468bbe02fa63c967
Reviewed-on: https://chromium-review.googlesource.com/378159
Reviewed-by: Mark Mentovai <mark@chromium.org>
This reverts commit 0fc6d0c8df because it
does not compile in Chromium due to the following error:
In file included from ../../breakpad/src/client/linux/minidump_writer/linux_dumper.h:43:0,
from ../../breakpad/src/client/linux/minidump_writer/minidump_writer.h:41,
from ../../breakpad/src/client/linux/handler/exception_handler.h:42,
from ../../components/crash/content/app/breakpad_linux.cc:44:
../../breakpad/src/common/android/include/link.h:46:9: error: multi-line comment [-Werror=comment]
#endif // !defined(__aarch64__) && !defined(__x86_64__) && \
^
> Don't define |r_debug| and |link_map| on Android releases 21 and later
>
> NDKs for Android 21 and later have the data structures |r_debug| and
> |link_map| defined in their header files. Defining them multiple times
> generates a compiler error.
>
> This patch protects both data structures from definition on Android 21
> and later.
>
> BUG=629088
> R=rmcilroy@chromium.org
>
> Review URL: https://codereview.chromium.org/2156173002 .
>
> Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
>
> Committed: 0ebdc4a10a
BUG=629088
Change-Id: Ia8d7d0eff060d661113e544d732813820bcb69e0
Reviewed-on: https://chromium-review.googlesource.com/367717
Reviewed-by: Mark Mentovai <mark@chromium.org>
NDKs for Android 21 and later have the data structures |r_debug| and
|link_map| defined in their header files. Defining them multiple times
generates a compiler error.
This patch protects both data structures from definition on Android 21
and later.
BUG=629088
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/2156173002 .
Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
Committed: 0ebdc4a10a
NDKs for Android 21 and later have the data structures |r_debug| and
|link_map| defined in their header files. Defining them multiple times
generates a compiler error.
This patch protects both data structures from definition on Android 21
and later.
BUG=629088
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/2156173002 .
Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
I'd like to have the Build ID available for our symbol server
uploading, and this will make it easy.
Most of this change is me rewriting dump_symbols_unittest to be
typed tests so I could add a new test there.
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/2052263002 .
A bunch of gtest assert statements fail due to signed warnings as
unadorned constants are treated as signed integers. Mark them all
unsigned to avoid that.
One example (focus on the "[with ...]" blocks that show the types):
In file included from src/breakpad_googletest_includes.h:33:0,
from src/common/memory_unittest.cc:30:
src/testing/gtest/include/gtest/gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int]':
src/testing/gtest/include/gtest/gtest.h:1524:23: required from 'static testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, const T2&, typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type*) [with T1 = int; T2 = long unsigned int; typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type = void]'
src/common/memory_unittest.cc:41:246: required from here
src/testing/gtest/include/gtest/gtest.h:1448:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (expected == actual) {
^
cc1plus: some warnings being treated as errors
Makefile:5180: recipe for target 'src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o' failed
make[2]: *** [src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o] Error 1
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/2013893003 .
We tried to use common/android/include/elf.h, however it contains
'#include-next elf.h' so it still breaks MAC build. So we use
third_party/musl/include/elf.h instead.
BUG=none
TEST=make; make test passes. There is no '#include-next elf.h' in
the new elf.h
R=michaelbai@chromium.org
Review URL: https://codereview.chromium.org/1994633003 .
It's possible for `IDiaSymbol::get_name` to return S_OK and provide
and empty string. I haven't figured out the exact root cause yet
(the symbols in question are coming from the Rust standard library),
but FUNC lines with missing function names break the processor and
so we should never do it. This change makes it output "<name omitted>"
which matches the behavior of the DWARF dumping code.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1272278
Review URL: https://codereview.chromium.org/1985643004 .
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 .
Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.
We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40: TAG_namespace [5] *
AT_name( "js" )
AT_decl_file( "../../dist/include/js/Utility.h" )
AT_decl_line( 35 )
0x11808500: TAG_subprogram [251] *
AT_low_pc( 0x0000000002f12110 )
AT_high_pc( 0x0000000002f1216b )
AT_APPLE_omit_frame_ptr( 0x01 )
AT_frame_base( rsp )
AT_abstract_origin( {0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_MIPS_linkage_name( "_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
AT_decl_file( "/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
AT_decl_line( 547 )
AT_external( 0x01 )
AT_APPLE_optimized( 0x01 )
AT_inline( DW_INL_inlined )
This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1887033002 .
