Previously, dump_syms produced warnings whenever a DW_AT_specification
or DW_AT_abstract_origin attribute was a forward reference. 47cd498384
allowed those attributes to carry forward references, removing the
warnings altogether. It was not correct to remove the warnings entirely.
References that do not point to valid DIEs should still produce
warnings, whether a back reference or a forward reference.
This reintroduces those warnings as appropriate.
Bug: google-breakpad:813
Test: dumper_unittest SimpleCU.UnknownAbstractOrigin,Specifications.BadOffset
Change-Id: Ie7222c7a1886bab31423f27e2fbcce93e69625b3
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2090103
Reviewed-by: Mike Frysinger <vapier@chromium.org>
DW_AT_specification and DW_AT_abstract_origin attributes carry
references to other DIEs. Nothing prevents the DIEs referred to from
appearing later in .debug_info than the DIE containing the referring
attribute, but dump_syms incompletly implemented its handling of these
references, and was only able to resolve them when they were
back-references.
This will fix the chronic warnings produced by dump_syms of the form:
dump_syms: the DIE at offset <offset> has a {DW_AT_specification,
DW_AT_abstract_origin} attribute referring to the die at offset
<offset>, which either was not marked as {a declaration, an inline}, or
comes later in the file
Patch by Greg Clayton
Bug: breakpad:441
Change-Id: I98957d64a234c22afb6d0153f1bdc09e6a600b1d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1946706
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>
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>
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 .
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 .
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 .
problems.
- The ordering of keys in stl containers cannot change. Make the relevant
members const to guarantee this assumption.
- Add handling and logging for demangle errors.
- Fix a potential double-delete bug if a function passed to AddFunction() is
already present.
BUG=chromium:449214
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/10704002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1415 4c0a9323-5329-0410-9bdc-e9ce6186880e
to add it to the specifications table. Record the fully-qualified name
provided by the demangler in the table.
A=Rafael Ávila de Espíndola <respindola@mozilla.com> R=jimb at https://breakpad.appspot.
com/478004/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1062 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch adds synth_elf::{StringTable,SymbolTable,ELF} classes to
produce in-memory ELF files to properly test the Linux symbol dumping
code. It also uses those classes to add some basic tests for
the WriteSymbolFile function.
R=jimb at http://breakpad.appspot.com/277001/show
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@794 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch makes sure dump_syms behaves properly when presented with
malformed DWARF data that provides no name for a function. We print a
warning message to stderr, and subsitute "<name omitted>" for the empty
string, so that the "FUNC" record written to the symbol file for the
function is still well-formed. (We may have line number data covering the
function, so it would be a shame to omit the function altogether.)
Unit tests included.
a=jimblandy, r=ted.mielczarek
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@779 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch avoids allocating many copies of identical strings appearing in
debugging information. Without this patch, running dump_syms on Mozilla's
libxul.so (with 173MiB of debugging information) has a peak resident set of
around 450MiB. With this patch, the peak is around 365MiB.
a=jimblandy, r=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@626 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch avoids unnecessary use of the <cfoo> headers in files that don't
actually use the identifiers they declare in the std:: namespace.
It also changes some files to better conform with the "Names and Order of
Includes" rules in the Google C++ Style Guide.
A=jimb R=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@619 4c0a9323-5329-0410-9bdc-e9ce6186880e
For some reason, Mac OS X places DWARF debugging information in sections
whose names begin with "__", rather than the names beginning with "." given
in the DWARF spec. This patch changes google_breakpad::DwarfCUToModule to
look for line number information under both names.
A=jimb R=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@612 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Linux symbol dumper's classes are reasonably portable, and should be
usable for the Mac dumper as well. Move them to src/common, along with
their unit tests. Update #include directives and Makefile.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@567 4c0a9323-5329-0410-9bdc-e9ce6186880e
2010-04-05 19:40:17 +00:00
Renamed from src/common/linux/dwarf_cu_to_module.cc (Browse further)
