aboutsummaryrefslogtreecommitdiff
path: root/autotools/depcomp
diff options
context:
space:
mode:
authorMark Mentovai <mark@chromium.org>2016-09-23 14:22:42 -0400
committerMark Mentovai <mark@chromium.org>2016-09-23 14:22:42 -0400
commit7398ce15b79daf038cd07fbae4e37e183e99788d (patch)
treec6baf6108bf8de9d23f9f574a8102196621b98fd /autotools/depcomp
parentgenerate a repo manifest from the DEPS file (diff)
downloadbreakpad-7398ce15b79daf038cd07fbae4e37e183e99788d.tar.xz
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 Review URL: https://codereview.chromium.org/2147523005 .
Diffstat (limited to 'autotools/depcomp')
0 files changed, 0 insertions, 0 deletions