From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id E01EE6ECCC; Thu, 18 Jun 2026 21:49:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E01EE6ECCC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1781808548; bh=eWJhY0tDfV1oH/WQT7OhtJBEC+7k90NYqYCHA0pG48Q=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=SMxg0nlhrl3vvWea1fWJOHi6zJ2OSfoZ6851Y8brOmxjQDHKC5IRQ8kI/Bs6kq7LC QyRmmLOACh9UsHYfetmvnVu9kFf/yr7tx9wEXhMQ+foH4fLh8+mFklRIDGzpZHn1zT c/aIyLmTjD2UNxQNsK4wvh3H+FwuYkU7zZ22T3Z0= Received: from send60.i.mail.ru (send60.i.mail.ru [89.221.237.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 05F496ECCC for ; Thu, 18 Jun 2026 21:49:06 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 05F496ECCC Received: by exim-smtp-795d79b7fd-v572z with esmtpa (envelope-from ) id 1waHnV-00000000Km3-0RMo; Thu, 18 Jun 2026 21:49:05 +0300 Date: Thu, 18 Jun 2026 21:48:25 +0300 To: Evgeniy Temirgaleev Message-ID: References: <20260604093052.2221827-1-skaplun@tarantool.org> <1781793399.19260190@f722.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1781793399.19260190@f722.i.mail.ru> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD946F1861C33760AE515B61F8C2060532B36B6736A49BEB3AC182A05F5380850401CA9B77448662FBD3DE06ABAFEAF6705F6E83527275FD73BB62131A9B7551F26D15A60FDECFA68C8 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72F22E6DC541F75D9EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AC83A81C8FD4AD23D82A6BABE6F325AC2E85FA5F3EDFCBAA7353EFBB553375664A4F0A6DC8BC205F765EE1C2C1321C323D8F508C2931043913DA21E705C42732389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B636DA1BED736F9328CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB86D1867E19FE14079C09775C1D3CA48CF3D321E7403792E342EB15956EA79C166A417C69337E82CC275ECD9A6C639B01B78DA827A17800CE7B2B7C64F398C7410731C566533BA786AA5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A56B360F3AA4B853CB5002B1117B3ED696846E04B9B574D41E9E040399BDE4761E823CB91A9FED034534781492E4B8EEADA3FB0D9844EF8EC5BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0AD73CAD6646DEDE1918E10F71CB4DF9F96AB70F9BE574AE9C625B6776AC983F447FC0B9F89525902EE6F57B2FD27647F25E66C117BDB76D6599CD8BED9D894AF5C5A4C043AED059D8BEC9BA45A095482EBFD5777B328BFD7630B36305FA0F886DAB8341EE9D5BE9A0A8A5D30950F4EFD21FB9ACCB701083C2338ACCBCA504EFB166536EB022892E5344C41F94D744909CECFA6C6B0C050A61A8CAF69B82BA93681CD72808BE417F3B9E0E7457915DAA85F X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXMZebaIdHP2ghjoIc/363UZI6Kf1ptIMVfwaKBAd4IJXvm8pFE3I0Jw= X-DA7885C5: E27C3AC17CF35ECFF255D290C0D534F9A1A06F4F91AB0F8F2DC78192FB9C85252D38187C6D4BDB755B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393520AF17B8A65FDE25ADA35AC0F31D77DC156C1C8AD991C2AE12C022302AE1E52E49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 0/4] Introduce dumpers for bytecodes in debuggers X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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