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
In r779, at the last moment, I added a default call count expectation for
the UnnamedFunction warning to the CUFixtureBase constructor, but didn't
re-run the tests. This patch adjusts all affected tests.
a=jimblandy, r=ted.mielczarek
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@782 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
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_unittest.cc (Browse further)
