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

[Evgeniy Temirgaleev]

Hi, Sergey! Thanks for the upgrade of the debuggers extension!

I try your updates in the Docker on Arm64 (M4 Pro chip). On the latest Ubuntu versions (24/26) all tests were passed now.

Under Ubuntu 20 it’s all ok for gcc build, and there are some fails with clang build. I think, this may be fixed later.

LGTM for all commits.

--
Best regards,
Evgeniy Temirgaleev

> 
> From: Sergey Kaplun <skaplun at tarantool.org>
> To: Evgeniy Temirgaleev <e.temirgaleev at tarantool.org>
> Cc: tarantool-patches at dev.tarantool.org, Sergey Bronnikov <sergeyb at tarantool.org
> >
> Date: Thursday, June 18, 2026 9:49 PM +03:00
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20260621/df5007f5/attachment.htm>