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 AAEB26ECD0; Mon, 29 Jun 2026 22:21:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AAEB26ECD0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1782760870; bh=656Sg3ElrNT9/QxnBNXsWfRHHOOrH0dKUIKi44y3xaM=; 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=mIwywDYNKT7qDCKehY1cKU2pnPAOtBKQc8hOL3A2Y+p467NqIb0/2iNvak+WReQjl HrKLhQCk0iY3KDp8EXOscPU0WuKwu2nuYVZY10duUs7q8a5XzTItaW2ojgoGGAT+dO bFcDtrhhXA1V3ax8KG5XC/LJB+Q/L78kYPaCPlnY= Received: from send57.i.mail.ru (send57.i.mail.ru [89.221.237.152]) (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 D71E56ECD0 for ; Mon, 29 Jun 2026 22:21:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D71E56ECD0 Received: by exim-smtp-78b8b8c574-sgzxs with esmtpa (envelope-from ) id 1weHXX-000000009Jo-3EP5; Mon, 29 Jun 2026 22:21:08 +0300 Date: Mon, 29 Jun 2026 22:20:28 +0300 To: Evgeniy Temirgaleev Message-ID: References: <20260625202903.3157425-1-skaplun@tarantool.org> <20260625202903.3157425-3-skaplun@tarantool.org> <1782741349.288346286@f466.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1782741349.288346286@f466.i.mail.ru> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD918D6BB028DF8CB61271EEA734090AF896B1E2CC942814F12182A05F5380850407778F54666A18FDC3DE06ABAFEAF670576EA993654679E25806C167858C344C2D8331305C3D564B6 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE70312E9A300D47E3BEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637FE9EFE935CD7C6AE8638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B230642FC5132895D92E070BE324C7D3C4C6C65FB18F5B5CA9F6B57BC7E64490618DEB871D839B73339E8FC8737B5C2249042F1592492B88C6CC7F00164DA146DAFE8445B8C89999729449624AB7ADAF37F6B57BC7E64490611E7FA7ABCAF51C92176DF2183F8FC7C0565C7A4E90E531F78941B15DA834481F9449624AB7ADAF372E808ACE2090B5E14AD6D5ED66289B5259CC434672EE63711DD303D21008E298D5E8D9A59859A8B6B372FE9A2E580EFC725E5C173C3A84C3C74813BC7F81EC8435872C767BF85DA2F004C90652538430E4A6367B16DE6309 X-C1DE0DAB: 0D63561A33F958A5D3A2A9BA7EB7762F5002B1117B3ED69650171877B94789EFFB820E9FE7BD014C823CB91A9FED034534781492E4B8EEAD2B25D9E4C92BC8ACBDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0AD73CAD6646DEDE191716CD42B3DD1D34CAB70F9BE574AE9C625B6776AC983F447FC0B9F89525902EE6F57B2FD27647F25E66C117BDB76D659E304D247F1C519B2DA1C7916ADA9C9184572F14DC7681CCE5F8A5D91753FD8195A8B399D33CABC87B8341EE9D5BE9A0A477E032F3262AE5B2DE81A68ECF761CAD89F204715444A6E6536EB022892E5344C41F94D744909CECFA6C6B0C050A61A8CAF69B82BA93681CD72808BE417F3B9E0E7457915DAA85F X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXMZebaIdHP2ghjoIc/363UZI6Kf1ptIMVRSZSJkMhZtM2LtXT0mBQ0A= X-DA7885C5: 0B9B02927ADA6C72F255D290C0D534F9B092B7E07DDC11BB691B3BA1CE57AF26BB9C267C1A2E96565B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393520AF17B8A65FDE2CF8BB7E0070C942B2DD8B301615801740AF96F972775B21FE49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 2/3] dbg: introduce lj-ctype command, extend cdata dump 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 29.06.26, Evgeniy Temirgaleev wrote: > Hi, Sergey! > > Thanks for the patch! > Please, see the commends below. > > -- > Best regards, > Evgeniy Temirgaleev > > > > > From: Sergey Kaplun > > To: Sergey Bronnikov , Evgeniy Temirgaleev > > > > Cc: tarantool-patches@dev.tarantool.org, Sergey Kaplun > > > > Date: Thursday, June 25, 2026 11:29 PM +03:00 > > This patch extends dumped information for the given cdata object. Now > > it resolves the given `CType` and prints it in the format similar to the > > `__tostring` metamethod. The `lj-ctype` command is introduced to dump > > this information where there is only the `CType` pointer but no cdata > > associated with it. > > > > `__or__` and `__ror__` metamethods are monkey-patched for the LLDB value > > object. In `__sub__` metamethod for LLDB pointers `GetPointeeType()` is > > used to get the pointee type instead of the incorrectly used > > `GetDereferencedType()` which always returns the same type with size 8. > > Casting from negative values to the unsigned values is supported to > > check `CTF_UCHAR`. > > > > Part of tarantool/tarantool#4808 > > --- > > src/luajit_dbg.py | 333 +++++++++++++++++- > > .../debug-extension-tests.py | 208 ++++++++++- > > 2 files changed, 535 insertions(+), 6 deletions(-) > > > > diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py > > index fd6ca8a5..62cd65d5 100644 > > --- a/src/luajit_dbg.py > > +++ b/src/luajit_dbg.py > > @@ -386,6 +386,8 @@ class _LLDBDebugger(Debugger): > > pack_flag = ' > else: > > pack_flag = ' > + # Cast to unsigned. > > > > Is /unsigned/uint64_t/ clearly? Rephrased as you suggested. Also, lowercase the value to be consistent with other hexademical values. =================================================================== diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py index 6b0827d9..0769f2ee 100644 --- a/src/luajit_dbg.py +++ b/src/luajit_dbg.py @@ -386,8 +386,8 @@ class _LLDBDebugger(Debugger): pack_flag = ' > > > > + raw_value &= 0xFFFFFFFFFFFFFFFF > > raw_data = struct.pack(pack_flag, raw_value) > > sbdata = lldb.SBData() > > sbdata.SetData( > > + > > + > > +def ctinfo(ct, flags): > > > > May we name this function ‘CTINFO’ as in ‘lj_ctype.h’? Or leave a comment with an original name for quick grep. Added a comment since the upper case is used for constants. =================================================================== diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py index 0769f2ee..de83a2b5 100644 --- a/src/luajit_dbg.py +++ b/src/luajit_dbg.py @@ -1427,6 +1427,7 @@ def ctype_attrib(info): return (info >> CTSHIFT_ATTRIB) & CTMASK_ATTRIB +# Implementation of the `CTINFO()` macro. def ctinfo(ct, flags): return (tou32(ct) << CTSHIFT_NUM) + flags =================================================================== > > > > > + return (tou32(ct) << CTSHIFT_NUM) + flags > > + > > + > > +def ctype_isptr(info): > > + return ctype_type(info) == CT_PTR > > + > > + > > +def ctype_iscomplex(info): > > + return (info & (CTMASK_NUM | CTF_COMPLEX)) == ctinfo(CT_ARRAY, > > CTF_COMPLEX) > > + > > + > > +def ctype_isinteger(info): > > + return (info & (CTMASK_NUM | CTF_BOOL | CTF_FP)) == ctinfo(CT_NUM, 0) > > + > > + > > +def ctype_isrefarray(info): > > + return (info & (CTMASK_NUM | CTF_VECTOR | CTF_COMPLEX)) == \ > > + ctinfo(CT_ARRAY, 0) > > + > > + > > +def ctype_cid(info): > > > > Let’s put these function definitions in the ‘lj_ctype.h’ order? > May we group the definitions by corresponding C files also? # lj_ctype.h … # lj_cdata.h … # lj_xxx.c … Sorted as you suggested. The sorting is the following: * lj_ctype.h * lj_cdata.h -- `cdata_getptr()` * lj_obj.h -- `cdataptr()` =================================================================== diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py index de83a2b5..183dda3b 100644 --- a/src/luajit_dbg.py +++ b/src/luajit_dbg.py @@ -1362,14 +1362,6 @@ def lightudV(tv): # FFI. -def ctype_ctsG(g): - return mref('CTState *', g['ctype_state']) - - -def ctype_get(cts, id): - return dbg.address(cts['tab'][id]) - - # Externally visible types. CT_NUM = 0 # Integer or floating-point numbers. CT_STRUCT = 1 # Struct or union. @@ -1419,46 +1411,55 @@ DWORDSZ = 4 QWORDSZ = 8 +# Implementation of the `CTINFO()` macro. +def ctinfo(ct, flags): + return (tou32(ct) << CTSHIFT_NUM) + flags + + def ctype_type(info): return info >> CTSHIFT_NUM -def ctype_attrib(info): - return (info >> CTSHIFT_ATTRIB) & CTMASK_ATTRIB +def ctype_cid(info): + return info & CTMASK_CID -# Implementation of the `CTINFO()` macro. -def ctinfo(ct, flags): - return (tou32(ct) << CTSHIFT_NUM) + flags +def ctype_attrib(info): + return (info >> CTSHIFT_ATTRIB) & CTMASK_ATTRIB def ctype_isptr(info): return ctype_type(info) == CT_PTR -def ctype_iscomplex(info): - return (info & (CTMASK_NUM | CTF_COMPLEX)) == ctinfo(CT_ARRAY, CTF_COMPLEX) - - def ctype_isinteger(info): return (info & (CTMASK_NUM | CTF_BOOL | CTF_FP)) == ctinfo(CT_NUM, 0) +def ctype_iscomplex(info): + return (info & (CTMASK_NUM | CTF_COMPLEX)) == ctinfo(CT_ARRAY, CTF_COMPLEX) + + def ctype_isrefarray(info): return (info & (CTMASK_NUM | CTF_VECTOR | CTF_COMPLEX)) == \ ctinfo(CT_ARRAY, 0) -def ctype_cid(info): - return info & CTMASK_CID - - def ctype_child(cts, ctype): return ctype_get(cts, ctype_cid(ctype['info'])) -def cdataptr(cd): - return dbg.cast('void *', (cd + 1)) +def ctype_ctsG(g): + return mref('CTState *', g['ctype_state']) + + +def ctype_get(cts, id): + return dbg.address(cts['tab'][id]) + + +# Get C type ID for a C type. +def ctype_typeid(cts, ct): + return ct - cts['tab'] def cdata_getptr(p, size): @@ -1468,9 +1469,8 @@ def cdata_getptr(p, size): return dbg.cast('void *', dbg.cast('uint64_t *', p)[0]) -# Get C type ID for a C type. -def ctype_typeid(cts, ct): - return ct - cts['tab'] +def cdataptr(cd): + return dbg.cast('void *', (cd + 1)) # JIT engine. =================================================================== > > > > > + return info & CTMASK_CID > > + > > + > > +def ctype_child(cts, ctype): > > + return ctype_get(cts, ctype_cid(ctype['info'])) > > + > > + > > +def cdataptr(cd): > > + return dbg.cast('void *', (cd + 1)) > > + > > + > > +def cdata_getptr(p, size): > > + if LJ_64 and size == 4: > > + return dbg.cast('void *', dbg.cast('uint32_t *', p)[0]) > > + else: > > > > assert for size == 8 ? Added since it may possibly lead to the incorrect (shrinked) pointer result. If we ever see the 16-bit pointers. Also, support the 32-bit systems (not LJ_64) as well. ================================================================ diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py index 183dda3b..de22d450 100644 --- a/src/luajit_dbg.py +++ b/src/luajit_dbg.py @@ -1463,9 +1463,10 @@ def ctype_typeid(cts, ct): def cdata_getptr(p, size): - if LJ_64 and size == 4: + if (LJ_64 and size == 4) or not LJ_64: return dbg.cast('void *', dbg.cast('uint32_t *', p)[0]) else: + assert size == 8, 'incorrect pointer size' return dbg.cast('void *', dbg.cast('uint64_t *', p)[0]) ================================================================ > > > > > + return dbg.cast('void *', dbg.cast('uint64_t *', p)[0]) > > + > > + > > +def ctype_prepnum(ctypestr, info, size): > > > > Func proto differs with lj_ctype.c (static void ctype_prepnum(CTRepr *ctr, uint32_t n)). > It seems, you move some of ctype_repr() code here. Let’s comment it? =================================================================== diff --git a/src/luajit_dbg.py b/src/luajit_dbg.py index de22d450..28cbe97d 100644 --- a/src/luajit_dbg.py +++ b/src/luajit_dbg.py @@ -2479,6 +2479,8 @@ def ctype_preptype(cts, ctypestr, ctype, qual, tp): return ctypestr +# Partially moved the code from `ctype_repr()` here to make it +# more readable. def ctype_prepnum(ctypestr, info, size): if info & CTF_BOOL: ctypestr = ctype_preplit(ctypestr, 'bool') =================================================================== > > +def dump_ctype(ct): > > > > Also, it seems, it will be easy to read to code, if it will be possible to distinguish between ported functions and extension itself ones. May be by use the ‘dbg_’ prefix for extension function names. I suppose this refactoring can be done in the separate issue. Since it is related to all functions. Also, the `dbg` is already used for the instance of the corresponding class. `dump_` prefix looks common for all dumpers of our extension. > > +class TestLJCTypeBase(TestCaseBase): > > + location = 'lj_cf_ffi_new' > > + extension_cmds = ( > > + # Load `ct`. Skip inlined functions for LLDB. > > > > The extension command set is common for GDB and LLDB. Does we skip for GDB also? For GDB this function isn't inlined, but these n-s are harmless. Adjusted the comment. =================================================================== diff --git a/test/tarantool-debugger-tests/debug-extension-tests.py b/test/tarantool-debugger-tests/debug-extension-tests.py index f17de27e..71b763d2 100644 --- a/test/tarantool-debugger-tests/debug-extension-tests.py +++ b/test/tarantool-debugger-tests/debug-extension-tests.py @@ -1033,7 +1033,9 @@ class TestLJCTypeFunc(TestCaseBase): class TestLJCTypeBase(TestCaseBase): location = 'lj_cf_ffi_new' extension_cmds = ( - # Load `ct`. Skip inlined functions for LLDB. + # Load `ct`. Skip inlined functions for LLDB. The skip is + # harmless for GDB since we are still in the body of the + # function. 'n\n' 'n\n' 'n\n' =================================================================== > > > > > + 'n\n' > > + 'n\n' > > + 'n\n' > > + 'n\n' > > + 'n\n' > > + 'n\n' > > + 'lj-ctype ct\n' > > + ) > > -- > > 2.54.0 > > -- Best regards, Sergey Kaplun