Initial support for dumping DWARF corresponding to Swift code

Initial support for dumping DWARF corresponding to Swift code

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

Committed: https://chromium.googlesource.com/breakpad/breakpad/+/7398ce15b79daf038cd07fbae4e37e183e99788d

[Mark Mentovai, 2016-07-13 18:06:12]

mark@chromium.org changed reviewers:
+ yunlian@chromium.org

[Mark Mentovai, 2016-07-13 18:06:13]

Yunlian, you’ve worked on the DWARF reader somewhat recently. Please let me know
if you’re not able to do this review.

[Mark Mentovai, 2016-07-13 20:59:48]

mark@chromium.org changed reviewers:
+ vapier@chromium.org
- yunlian@chromium.org

[Mark Mentovai, 2016-07-13 20:59:48]

Yunlian is out, but it looks like vapier’s also been in here lately.

[Mark Mentovai, 2016-09-13 19:30:44]

Description was changed from

==========
Initial support for dumping DWARF corresponding to Swift code

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.

Swift uses dots for separating nested scopes as in Java.

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 presumably DW_AT_linkage_name in the
upcoming DWARF 5) 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 currently dropped in favor of using names derived from
DW_AT_name attributes in nested scopes (including DW_TAG_module,
DW_TAG_subprogram, etc.)

BUG=google-breakpad:702
==========

to

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

[Mark Mentovai, 2016-09-13 19:32:11]

Description was changed from

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

to

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

[Mark Mentovai, 2016-09-13 19:32:11]

mark@chromium.org changed reviewers:
+ yunlian@chromium.org
- vapier@chromium.org

[Mark Mentovai, 2016-09-13 19:33:15]

Updated. By request, this now passes mangled Swift names straight through to
dump_syms’ output. “xcrun swift-demangle” can post-process this to produce
something more readable.

[Ted Mielczarek, 2016-09-13 19:38:42]

On 2016/09/13 19:33:15, Mark Mentovai wrote:
> Updated. By request, this now passes mangled Swift names straight through to
> dump_syms’ output. “xcrun swift-demangle” can post-process this to
produce
> something more readable.

We've got a similar issue with Rust symbol names in Firefox FWIW, we're likely
going to wind up doing the same. (Rust actually uses g++-style mangling so it
demangles mostly sensibly on Linux/Mac, but not on Windows.)

[Mark Mentovai, 2016-09-13 19:41:17]

mark@chromium.org changed reviewers:
+ ted.mielczarek@gmail.com

[Mark Mentovai, 2016-09-13 19:41:17]

Cool. Although it sounds like we can demangle Rust where __cxa_demangle is
available, and require post-processing on Windows, then?

If you review mine, I’ll review yours!

[Ted Mielczarek, 2016-09-13 20:02:35]

On 2016/09/13 19:41:17, Mark Mentovai wrote:
> Cool. Although it sounds like we can demangle Rust where __cxa_demangle is
> available, and require post-processing on Windows, then?
> 
> If you review mine, I’ll review yours!

Yeah, it doesn't demangle to *exactly* the Rust symbol with __cxa_demangle (it's
an approximation), but it's readable. Helpfully there is already a Rust library
to demangle Rust symbols, and I wired it up into a little binary, I just haven't
hooked it into our symbol processing yet: https://github.com/luser/rustfilt

-Ted

[vapier, 2016-09-14 05:14:21]

vapier@chromium.org changed reviewers:
+ vapier@chromium.org

[vapier, 2016-09-14 05:14:22]

i'm not terribly familiar with the dwarf dumping code, so i'm not the best for
this

[Ted Mielczarek, 2016-09-14 10:20:10]

LGO

This was surprisingly not that hard to review considering it's touching DWARF
handling code!

https://codereview.chromium.org/2147523005/diff/20001/src/common/dwarf_cu_to_...
File src/common/dwarf_cu_to_module.cc (right):

https://codereview.chromium.org/2147523005/diff/20001/src/common/dwarf_cu_to_...
src/common/dwarf_cu_to_module.cc:356: if (status != Language::kDontDemangle) {
It's unfortunate that we lose the language context here when we translate to
.sym format. It would be nice to be able to demangle reliably instead of having
to guess. (I suppose it's not that hard to guess, though, given the mangled
symbol prefix.)

https://codereview.chromium.org/2147523005/diff/20001/src/common/language.cc
File src/common/language.cc (right):

https://codereview.chromium.org/2147523005/diff/20001/src/common/language.cc#...
src/common/language.cc:79: #endif
This seems like it'd be clearer to read if it was just:
#if defined(__ANDROID__)
  return whatever;
#else
  // actually try to demangle
#endif

https://codereview.chromium.org/2147523005/diff/20001/src/common/language.h
File src/common/language.h (right):

https://codereview.chromium.org/2147523005/diff/20001/src/common/language.h#n...
src/common/language.h:88: virtual int DemangleName(const string& mangled,
std::string* demangled)
I think it would be better to make this return an enum with three possible
values:
* Success
* Failure
* DontDemangle

The `__cxa_demangle` status codes aren't likely to be of any use to the caller
anyway.

[Mark Mentovai, 2016-09-21 17:56:56]

Thanks for the review, Ted! I’ve implemented your suggestions.

https://codereview.chromium.org/2147523005/diff/20001/src/common/dwarf_cu_to_...
File src/common/dwarf_cu_to_module.cc (right):

https://codereview.chromium.org/2147523005/diff/20001/src/common/dwarf_cu_to_...
src/common/dwarf_cu_to_module.cc:356: if (status != Language::kDontDemangle) {
Ted Mielczarek wrote:
> It's unfortunate that we lose the language context here when we translate to
> .sym format. It would be nice to be able to demangle reliably instead of
having
> to guess. (I suppose it's not that hard to guess, though, given the mangled
> symbol prefix.)

In the future, maybe we can spin up a pipe to swift-demangle to get these in
dump_syms instead of relying on post-processing. That’d still only work if
swift-demangle was available, but it’s something…

[Ted Mielczarek, 2016-09-23 14:28:44]

LGTM with one fix.

https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc
File src/common/language.cc (right):

https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc#...
src/common/language.cc:77: #endif
You need to wrap the rest of the function body in an #else, since __cxa_demangle
won't even compile on Android.

[Mark Mentovai, 2016-09-23 18:15:52]

Description was changed from

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

to

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

[Mark Mentovai, 2016-09-23 18:22:26]

Ted Mielczarek wrote:
> LGTM with one fix.
> 
> https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc
> File src/common/language.cc (right):
> 
>
https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc#...
> src/common/language.cc:77: #endif
> You need to wrap the rest of the function body in an #else, since
__cxa_demangle
> won't even compile on Android.

Thanks, Ted. Good catch.

[Mark Mentovai, 2016-09-23 18:22:45]

Description was changed from

==========
Initial support for dumping DWARF corresponding to Swift code

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
==========

to

==========
Initial support for dumping DWARF corresponding to Swift code

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

Committed:
https://chromium.googlesource.com/breakpad/breakpad/+/7398ce15b79daf038cd07fb...
==========

[Mark Mentovai, 2016-09-23 18:22:46]

Committed patchset #4 (id:60001) manually as
7398ce15b79daf038cd07fbae4e37e183e99788d (presubmit successful).

[dawikur, 2016-09-26 13:28:02]

dawikur@gmail.com changed reviewers:
+ dawikur@gmail.com

[dawikur, 2016-09-26 13:28:03]

https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc
File src/common/language.cc (right):

https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc#...
src/common/language.cc:89: demangled->assign(demangled_c);
It is possible that demangled_c here is nullptr, which breaks
std::string::assign contract and is causing SEGFAULT.

[Mark Mentovai, 2016-09-26 13:40:57]

dawikur wrote:
> https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc
> File src/common/language.cc (right):
> 
>
https://codereview.chromium.org/2147523005/diff/40001/src/common/language.cc#...
> src/common/language.cc:89: demangled->assign(demangled_c);
> It is possible that demangled_c here is nullptr, which breaks
> std::string::assign contract and is causing SEGFAULT.

I don’t know how I managed to swap the success and failure branches, but
https://chromium-review.googlesource.com/389411 will fix it.