[LLDB] Finish implementing support for DW_FORM_data16

[walter-erquinigo]

This FORM already has support within LLDB to be parsed as a 16-byte BLOCK, and all that is left to properly support it in the DWARFParser is to add it to some enums.

With this, I can debug programs that use libstdc++.so.6.0.33 built with GCC.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Walter Erquinigo (walter-erquinigo)

Changes

This FORM already has support within LLDB to be parsed as a 16-byte BLOCK, and all that is left to properly support it in the DWARFParser is to add it to some enums.

With this, I can debug programs that use libstdc++.so.6.0.33 built with GCC.

---

Full diff: https://github.com/llvm/llvm-project/pull/113508.diff

2 Files Affected:

• (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp (+7)
• (modified) lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s (+13-1)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
index f58c6262349c6f..404e50d57a9251 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -306,6 +306,11 @@ bool DWARFFormValue::SkipValue(dw_form_t form,
       *offset_ptr += 8;
       return true;
 
+    // 16 byte values
+    case DW_FORM_data16:
+      *offset_ptr += 16;
+      return true;
+
     // signed or unsigned LEB 128 values
     case DW_FORM_addrx:
     case DW_FORM_loclistx:
@@ -578,6 +583,7 @@ bool DWARFFormValue::IsBlockForm(const dw_form_t form) {
   case DW_FORM_block1:
   case DW_FORM_block2:
   case DW_FORM_block4:
+  case DW_FORM_data16:
     return true;
   default:
     return false;
@@ -611,6 +617,7 @@ bool DWARFFormValue::FormIsSupported(dw_form_t form) {
     case DW_FORM_data2:
     case DW_FORM_data4:
     case DW_FORM_data8:
+    case DW_FORM_data16:
     case DW_FORM_string:
     case DW_FORM_block:
     case DW_FORM_block1:
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s b/lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s
index 720684c19beebc..731a558f3e572d 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/DW_AT_const_value.s
@@ -3,7 +3,7 @@
 
 # RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux %s -o %t
 # RUN: %lldb %t \
-# RUN:   -o "target variable udata data1 data2 data4 data8 string strp ref4 udata_ptr" \
+# RUN:   -o "target variable udata data1 data2 data4 data8 data16 string strp ref4 udata_ptr" \
 # RUN:   -o exit | FileCheck %s
 
 # CHECK-LABEL: target variable
@@ -14,6 +14,7 @@
 # CHECK: (unsigned long) data2 = 4742
 # CHECK: (unsigned long) data4 = 47424742
 # CHECK: (unsigned long) data8 = 4742474247424742
+# CHECK: (unsigned __int128) data16 = 129440743495415807670381713415221633377
 ## Variables specified using string forms. This behavior purely speculative -- I
 ## don't know of any compiler that would represent character strings this way.
 # CHECK: (char[7]) string = "string"
@@ -88,6 +89,7 @@
         var 15, 0x8                     # DW_FORM_string
         var 16, 0xe                     # DW_FORM_strp
         var 17, 0x13                    # DW_FORM_ref4
+        var 18, 0x1e                    # DW_FORM_data16
         .byte   0                       # EOM(3)
         .section        .debug_info,"",@progbits
 .Lcu_begin0:
@@ -119,6 +121,11 @@
 .Lulong_ptr:
         .byte   2                       # Abbrev DW_TAG_pointer_type
         .long   .Lulong-.Lcu_begin0     # DW_AT_type
+.Lu128:
+        .byte   6                       # Abbrev DW_TAG_base_type
+        .asciz  "Lu128"                 # DW_AT_name
+        .byte   16                      # DW_AT_byte_size
+        .byte   7                       # DW_AT_encoding
 
         .byte   10                      # Abbrev DW_TAG_variable
         .asciz  "udata"                 # DW_AT_name
@@ -165,6 +172,11 @@
         .long   .Lulong_ptr-.Lcu_begin0 # DW_AT_type
         .uleb128 0xdeadbeefbaadf00d     # DW_AT_const_value
 
+        .byte   18                      # Abbrev DW_TAG_variable
+        .asciz  "data16"                # DW_AT_name
+        .long   .Lu128-.Lcu_begin0      # DW_AT_type
+        .asciz "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"     # DW_AT_const_value
+
         .byte   0                       # End Of Children Mark
 .Ldebug_info_end0:
 

[jasonmolenda]

Looks good to me, but Adrian might want a look.

[walter-erquinigo]

Friendly ping, otherwise I'll merge it in a couple of days

[labath]

This doesn't sound right. Shouldn't this be a 128 bit integer value? I'd also recommend writing the variable in a way that's easily recognisable as "correct" in the test expectations. Since we don't have a way (AFAIK) to insert 128 bit asm constants, I'd probably do it by putting two .quad 0xhex statements here and then telling lldb to print the variable in hex (by adding an extra target variable --format x data16 command)

[walter-erquinigo]

That's a good idea. I'll try that out!

[adrian-prantl]

I think the code itself seems fine, especially if Pavel's suggestion shows that the test works.

[labath]

I think the code itself seems fine, especially if Pavel's suggestion shows that the test works.

I actually did check that 129440743495415807670381713415221633377 is 0x61616161616161616161616161616161 (and it seems that the dwarf parser is robust enough to ignore the extra aaaas at the end). But this is not a test for the handling of malformed dwarf..

[walter-erquinigo]

I was able to make it work using @labath 's suggestion. Fortunately it just works.
Please give it another look :)

[labath]

LGTM