Re: [Tarantool-patches] [PATCH luajit 0/4] Introduce dumpers for bytecodes in debuggers

[Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Hi, Evgeniy!
Thanks for the review!
Fixed your comments and force-pushed the branch.

On 18.06.26, Evgeniy Temirgaleev wrote:
> Hi, Sergey! Thanks for the patch!
> 
> I tried the tests under Ubuntu 20.04 and Ubuntu 24.04 with gcc and clang LuaJIT builds:
> 
> 1) Ubuntu 20 + gcc: all tests were passed.
> 2) Ubuntu 20 + clang: some of gdb and lldb tests were failed.
> 3) Ubuntu 24 + gcc: some of lldb tests were failed.
> 4) Ubuntu 24 + clang: some of gdb and lldb tests were failed.

Thanks a lot for these catches!

Ubuntu 24 has LLDB (18) with regression. It can't use the array object
as the initializer for `lldb.value`. This regression affects versions 17
- 19. See [1] for the details.

I've added the corresponding workaround for it:
===================================================================
diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py
index 3a3ca9b8..2edb199a 100644
--- a/src/luajit_dbg.py
+++ b/src/luajit_dbg.py
@@ -324,7 +324,7 @@ class _LLDBDebugger(Debugger):
                 key = int(key)
             if type(key) is int:
                 # Allow array access.
-                if key >= 0:
+                if key >= 0 and not lldbval.sbvalue.TypeIsPointerType():
                     return lldb.value(
                         lldbval.sbvalue.GetValueForExpressionPath('[%i]' % key)
                     )
@@ -475,7 +475,22 @@ class _LLDBDebugger(Debugger):
         return strptr.sbvalue.summary
 
     def lookup_global(self, symbol):
-        return lldb.value(self.target.FindFirstGlobalVariable(symbol))
+        sbvalue = self.target.FindFirstGlobalVariable(symbol)
+        tp = sbvalue.GetType()
+        # XXX: LLDB in versions 17 - 19 can't use an array object
+        # as the initializer for `lldb.value` since `GetValue()`
+        # for it returns `None` leading to the invalid result.
+        # See https://github.com/llvm/llvm-project/pull/90144.
+        if (self.version < 17 or self.version > 19) or \
+           tp.GetTypeClass() != lldb.eTypeClassArray:
+            return lldb.value(sbvalue)
+        else:
+            ptr_tp = tp.GetArrayElementType().GetPointerType()
+            return self._lldb_value_from_raw(
+                sbvalue.GetLoadAddress(),
+                ptr_tp.GetByteSize(),
+                ptr_tp
+            )
 
     def eval(self, command):
         if not command:
===================================================================

Regarding clang issues, I suppose this is due to not enough dwarf
information about the macro definitions. That leads to test failures
(even if the extension works correctly).

I've added the following fix with detecting is the required macro
definitions supported. Patch is splitted via the corresponding commits.
===================================================================
diff --git a/test/tarantool-debugger-tests/debug-extension-tests.py b/test/tarantool-debugger-tests/debug-extension-tests.py
index b677942c..7e8ea5a2 100644
--- a/test/tarantool-debugger-tests/debug-extension-tests.py
+++ b/test/tarantool-debugger-tests/debug-extension-tests.py
@@ -97,6 +97,10 @@ IS_DUALNUM = execute_process([
     LUAJIT_BINARY, '-e', "print(require('ffi').abi('dualnum'))"
 ]).strip() == 'true'
 
+IS_GC64 = execute_process([
+    LUAJIT_BINARY, '-e', "print(require('ffi').abi('gc64'))"
+]).strip() == 'true'
+
 # If it is the guaranteed DUALNUM build (for example, on aarch64),
 # we use this regexp for the guaranteed 'integer' check and
 # 'number' for single-number build.
@@ -139,23 +143,54 @@ class TestCaseBase(unittest.TestCase):
             self.assertRegex(self.output, self.pattern.strip())
 
 
-# LLDB + Clang on macOS can't produce debug info for the C-defined
-# macros. Thus, we hardcoded its value manually.
+# Test that the emitted debug information supports macro
+# definitions.
+def check_macro_debug_info():
+    cmd_file = persist('\n'.join([
+        'b lj_cf_print',
+        *PROCESS_RUN,
+        'n',
+        'p gcval(L->base)',
+        'q',
+    ]))
+    process_cmd = [
+        DEBUGGER,
+        *RUN_CMD_FILE,
+        cmd_file.name,
+        INFERIOR_ARGS,
+        LUAJIT_BINARY,
+        '-e',
+        'print("")'
+    ]
+    output = execute_process(process_cmd)
+    cmd_file.close()
+    return re.search(r'\(GCobj \*\) ' + RX_ADDR, output) is not None
+
+
+SUPPORT_MACRO_EXPAND = check_macro_debug_info()
+
+
+# LLDB + Clang on macOS (for example) can't produce debug info
+# for the C-defined macros. Thus, we hardcoded its value manually.
 def gcval(arg):
-    if sys.platform == 'darwin':
-        # Assume GC64 build only.
-        LJ_GCVMASK = '(((uint64_t)1 << 47) - 1)'
-        return '(((' + arg + ')->gcr).gcptr64 & ' + LJ_GCVMASK + ')'
-    else:
+    if SUPPORT_MACRO_EXPAND:
         return 'gcval(' + arg + ')'
+    else:
+        if IS_GC64:
+            LJ_GCVMASK = '(((uint64_t)1 << 47) - 1)'
+            return '(((' + arg + ')->gcr).gcptr64 & ' + LJ_GCVMASK + ')'
+        else:
+            return '((' + arg + ')->gcr).gcptr32'
 
 
 def mref(arg, tp):
-    if sys.platform == 'darwin':
-        # Assume GC64 build only.
-        return '((' + tp + '*)(' + arg + ').ptr64)'
-    else:
+    if SUPPORT_MACRO_EXPAND:
         return 'mref(' + arg + ', ' + tp + ')'
+    else:
+        if IS_GC64:
+            return '((' + tp + '*)(' + arg + ').ptr64)'
+        else:
+            return '((' + tp + '*)(' + arg + ').ptr32)'
 
 
 class TestLoad(TestCaseBase):
===================================================================

I've checked in Ubuntu 24/26 Dockers, our CI (Ubuntu 20), and macOS M1.
Tests don't fail anymore.

> 
> --
> Best regards,
> Evgeniy Temirgaleev
> 

<snipped>

[1]: https://github.com/llvm/llvm-project/pull/90144

-- 
Best regards,
Sergey Kaplun