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 > To: Evgeniy Temirgaleev > Cc: tarantool-patches@dev.tarantool.org, Sergey Bronnikov > > 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 > > > > > > [1]: https://github.com/llvm/llvm-project/pull/90144 > > -- > Best regards, > Sergey Kaplun >