[Lldb-commits] [PATCH] D40283: lldb: Use the DWARF linkage name when importing C++ methods

[Nelson Elhage via Phabricator via lldb-commits]

nelhage added a comment.

In https://reviews.llvm.org/D40283#936088, @clayborg wrote:

> Jim will need to ok this. A few concerns follow. Most of the time when we don't get the DWARF -> AST conversion right, it can mean that we might code gen incorrect code. Is there not enough information for the GNU abi_tag in the DWARF to actually re-create these classes correctly in the AST?


Correct, as far as I can tell. Looking at a symbol definition from the test program on the issue via `llvm-dwarfdump`, I see

  0x00000076:     DW_TAG_subprogram
                    DW_AT_linkage_name    ("_ZN1A16helloWorld_cxx11B5cxx11Ev")
                    DW_AT_name    ("helloWorld_cxx11")
                    DW_AT_decl_file       ("/tmp/test_abi_tag.cc")
                    DW_AT_decl_line       (5)
                    DW_AT_declaration     (true)
                    DW_AT_external        (true)
                    DW_AT_accessibility   (DW_ACCESS_public)
  
  0x00000082:       DW_TAG_formal_parameter
                      DW_AT_type  (cu + 0x009b "A*")
                      DW_AT_artificial    (true)
  
  0x00000087:       NULL

The function of the `abi_tag` annotation is to append the `B5cxx11` to the mangled name; I can't find any other indication in the DWARF of the ABI tag.

You can read more about `abi_tag` here:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
Or an explanation of why it exists and how it is used here:
https://davmac.wordpress.com/2015/07/19/tale-of-two-abis/

The effect of this patch on the code generated by `expression` is to change the names we emit into the LLVM IR; Previously, we would emit a call to `_ZN1A16helloWorld_cxx11Ev`, which would then fail when resolving symbols. Now we (correctly) emit a call to `_ZN1A16helloWorld_cxx11B5cxx11Ev`.

The test case I added in this patch also demonstrates that GCC and clang both support arbitrarily overriding a symbol's mangled name in the source using `asm("new_name")`. I can't recall having ever encountered a use of that in the wild, so I don't care strongly about supporting it, but if we want to I think this general approach is almost certainly the only approach that would do so.


https://reviews.llvm.org/D40283