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 3174E6EC40; Wed, 11 Aug 2021 11:28:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3174E6EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628670521; bh=cH3pmn5WhbhNYFt3JfXiUlr5Y70ttdZr1xmTUWPi6VY=; 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=oePYUy3Z9MyYFHRWxeSJKgBvu4XPqU2ErPDOr2A+1pOThH6OM9nNJft63vXRdTNw1 doSq8f5tpm614frsZzfrfqbSsR4ImsCRgcNsPdhDQk1de02ufWlLRnsvp2scECV/+6 ml3wQREvYex/g6mBxE/ako9yyg5NDLi2rSEDAIYc= Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 42F7B6EC40 for ; Wed, 11 Aug 2021 11:28:39 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 42F7B6EC40 Received: by smtp47.i.mail.ru with esmtpa (envelope-from ) id 1mDjbK-0005nu-Af; Wed, 11 Aug 2021 11:28:38 +0300 Date: Wed, 11 Aug 2021 11:27:22 +0300 To: Maxim Kokryashkin Message-ID: References: <20210731133648.25660-1-m.kokryashkin@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210731133648.25660-1-m.kokryashkin@tarantool.org> X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD9ECFD080E047A606F6525B29142351271182A05F538085040ADD5D97F900F6D829797E91862F151133156486A9F684B21B5F5CC603B3DE060 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE73870E1FF9A049D91EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375B4C42A189C515578638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D86E2090891E1D881D78AECD2B44891A09117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751FF04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B613439FA09F3DCB32089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A53E836225E73FC7F9195C04A0F6655B4E9259D0EA9C63D563D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA753177526CD55AFC11410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D348B532EA2091F4FF671C7B443C89733EAAC3DB0CF3621E303B846E7C3106D37658E893E21AE7F514A1D7E09C32AA3244C2FBEAED5BFA5520ADAA47336C21703A21DD47778AE04E04D927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj6qlzQV0oSZOhoowgTJSexQ== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB45CBCEA0ED9B827B9DDDDA38A072F342E6A4A96B2535DF121F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] luajit-gdb: support dualnum mode 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, Maxim! Thanks for the patch! Please consider my comments below. Side note: First of all, I'm very disappointed, that there this patch [1] isn't merged (in any form) into gdb. Those work with the expanding of macros is very helpful... On 31.07.21, Maxim Kokryashkin wrote: > For x86/x64 LJ_DUALNUM mode is disabled. But for some other arches Nit: It can be enabled by corresponding configuration options for x86/x64, too, IINM. So I suggest to drop the first and the second sentence. > (arm or arm64, for example) it is enabled by default. luajit-gdb.py > displays integers in LJ_DUALNUM mode as nan-s. > Nit: This paragraph may be joined to the next after suggesting changes. > As it turned out, luajit-gdb detects those integers as integers, but > there was a problem with the dumper function itself. Nit: The next sentence is about the problem with the dumping function, so I suggest to drop this opening sentence:) Feel free to ignore. > The dumper > function produces output thinking of any input value as of a double. > However, in DUALNUM mode, integers and floats are stored differently, Typo: s/floats/doubles/ Here and below. > so the `itype` of a float number must be less than `LJ_TISNUM`, and the > `itype` of an integer must be `LJ_TISNUM`. With this fact in mind, we > can easily differentiate one from another. > > But in any mode, lua numbers are stored as doubles on the C side, so it Typo: s/lua/Lua/ Do you mean LuaJIT here? Because this is not true for LuaJIT. See for details. > takes an ugly cast chain on the Python side to perform the some sort of > the `reinterpret_cast` because the gdb module doesn't have any > mechanism to get the address of a symbol. This sentence isn't clear to me. What symbol do you mean? > > Closes tarantool/tarantool#6224 Side note: You can say that it really closes the issue, because we use luajit-gdb from this fork. OTOH, maybe one uses it as a part of third_party from Tarantool repo. "Closes" is good to me, but I'm not sure what is idiomatically correct. > --- > Github branch: https://github.com/tarantool/luajit/tree/fckxorg/gh-6224-support-dulanum > Issue: https://github.com/tarantool/tarantool/issues/6224 > For more info, see line 273 in lj_obj.h > > src/luajit-gdb.py | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/src/luajit-gdb.py b/src/luajit-gdb.py > index c50405ad..5f79c277 100644 > --- a/src/luajit-gdb.py > +++ b/src/luajit-gdb.py > @@ -343,7 +343,11 @@ def dump_lj_tudata(tv): > return 'userdata @ {}'.format(strx64(gcval(tv['gcr']))) > > def dump_lj_tnumx(tv): > - return 'number {}'.format(cast('double', tv['n'])) > + if itype(tv) == (0xfffeffff if LJ_64 and not LJ_GC64 else LJ_T['NUMX']): This is true only in LJ_DUALNUM mode. So I suggest we can add another one global constant for this: LJ_DUALNUM. We can set it via hack with lookuping symbol `lj_lib_checknumber` -- it is compiled only for LJ_DUALNUM mode for now. So, if a result of lookup() isn't None we are in LJ_DUALNUM mode. Also, I suggest to create another global constant for LJ_TISNUM, like it is done for PADDING constant. I suppose we want to do something similar to tvisint() macro for this check: | LJ_DUALNUM && itype(tv) == LJ_TISNUM > + integer = cast('int32_t', cast('uint64_t', cast('void*', tv['n'])) & 0xFFFFFFFF) I don't get this cast to uint64_t and mask. Why can't we just take `(int32_t)(o)->i` value, like it is done for `intV()` macro? > + return 'number {}'.format(integer) Nit: I suppose, it is better to highlight the fact that TValue stores integer here with corresponding return. It may be helpful for debugging some issues, related to storing type, I suppose. But I'm not so sure at this point. Wait for Igor's opinion. > + else: > + return 'number {}'.format(cast('double', tv['n'])) > > def dump_lj_invalid(tv): > return 'not valid type @ {}'.format(strx64(gcval(tv['gcr']))) > -- > 2.32.0 > [1]: https://sourceware.org/legacy-ml/gdb-patches/2011-08/msg00441.html -- Best regards, Sergey Kaplun