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 C5B42C96C66; Thu, 18 Apr 2024 11:04:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C5B42C96C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1713427461; bh=2Ue69teNtSOH/DNE/62MG7a40/Pvs4twM/f44MLRTHE=; 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=Gget2vlRWnOiHOqbqDe+vnqH93/7BnzzY2y+YO0qQd1pmXhB0KHGQEepV7SBDGeo3 X+XGjVAidITRxYYKvjmau30/oOBHxljEMDpxJQd6RYRjBNB9ooWtoPOtzr7ZFp5PIt MAy4MeMHlquStvhl/YHWenoAl9bVAlRzffAkFwyc= Received: from smtp35.i.mail.ru (smtp35.i.mail.ru [95.163.41.76]) (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 8252EC96C66 for ; Thu, 18 Apr 2024 11:04:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 8252EC96C66 Received: by smtp35.i.mail.ru with esmtpa (envelope-from ) id 1rxMkk-00000006JdQ-22w3; Thu, 18 Apr 2024 11:04:18 +0300 Date: Thu, 18 Apr 2024 11:00:14 +0300 To: Maxim Kokryashkin Message-ID: References: <13501abba00ac3e072284d36a531c721e279722f.1712182830.git.m.kokryashkin@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9F97E3C14763C38E25E23AD2F753BC837AACC553519710C57182A05F53808504000D42F16162DF7012EB5D77EF37489D187F000D2CDB2056C7B01ED76D1C6E3CB32F1CFC60563ED00 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F9D3BE5B596754B8C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7ECD3FEFFF0C7120D8F08D7030A58E5AD1A62830130A00468AEEEE3FBA3A834EE7353EFBB55337566FF11C0C56882C469B538B7A0697926241A22604D354AABEB37446DA980EE8835389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C04A3B2F4BA56A4D558941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6668FBEE05F116134CC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB86D1867E19FE14079C09775C1D3CA48CF17B107DEF921CE791DD303D21008E298D5E8D9A59859A8B6B372FE9A2E580EFC725E5C173C3A84C3BE90F13D913F449135872C767BF85DA2F004C90652538430E4A6367B16DE6309 X-C1DE0DAB: 0D63561A33F958A52F908A73D22BEC085002B1117B3ED69645F6A1E32DFE367503803A57F48E4E5A823CB91A9FED034534781492E4B8EEADA3A806F356AF31D6 X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D341C998A3771F0415334C81C78B396C17A92F451747408071A29A959B50B02CE044D96940E76E61ED61D7E09C32AA3244C0D22AC3C12FD35ABA0CBE312C330D7D5DFB59376F7B7C183EA455F16B58544A21C197AAF4D2E4732A5AE236DF995FB59829709634694AABAED6A17656DB59BCAD427812AF56FC65B X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojHFx/al5BK5EVf8YJkkJRsA== X-DA7885C5: 71E645DB4ABCEBF0F255D290C0D534F9D99B1D2C6C02B9089BF7833A5CC02E20BD7472F53B14EC2E5B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393590D8C940224AE3335F224F918DF7C23001506E5729D11F66900F914ECEEC13FE49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v6 1/2] debug: generalized extension 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: Maxim Kokryashkin , tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Maxim! Thanks for the fixes! Unfortunately, I am troubled with other regressions. Assume, we run the following command: | gdb --args src/luajit -e 'print(1)' and try to load the extension before running the child process. Then we got the following error: | (gdb) b lj_cf_print | Breakpoint 1 at 0x39ce3: file /home/burii/reviews/luajit/lj-dbg/src/lib_base.c, line 496. | (gdb) source src/luajit_dbg.py | LuaJIT debug extension failed to load: no debugging symbols found for libluajit While the original gdb extension is loaded as expected: | (gdb) source ~/builds_workspace/luajit/master/src/luajit-gdb.py | lj-arch command initialized | lj-tv command initialized | lj-str command initialized | lj-tab command initialized | lj-stack command initialized | lj-state command initialized | lj-gc command initialized | luajit-gdb.py is successfully loaded Also, when I used something like the following for the generalized debugger extension, I got the following: | (gdb) lj-stack 0x0 | ---------- Red zone: 5 slots ---------- | 0x40001a80 [ ] VALUE: nil | ... | (gdb) info locals | i = 0 | nargs = 93824992266313 | tv = 0x0 | __func__ = "lj_cf_print" | shortcut = 21845 | (gdb) lj-stack tv | ---------- Red zone: 5 slots ---------- | ... While in the old version of debugger I got the following output: | (gdb) lj-stack tv | table argument empty | (gdb) lj-stack 0x0 | table argument empty I suppose, that the new debugger extension version used default global `main_L` when the given argument is 0. On 18.04.24, Maxim Kokryashkin wrote: > Hi, Sergey! > Thanks for the review! > See my answers below. > On Wed, Apr 17, 2024 at 07:00:00PM +0300, Sergey Kaplun wrote: > > > - > > > - ret = frame.EvaluateExpression(command) > > > - return ret > > > + return dbg.to_unsigned(dbg.eval(command)) > > > > Why do we need return unsigned here? > Because all of our commands accept either pointers, or numbers as > argumnents and lldb's eval may return a string instead. Got it thanks! A comment will be appreciated. > > > > > > > > @abc.abstractproperty > > > def command(self): > > > @@ -270,7 +491,7 @@ class Command(object): > > > > > > > > > @@ -278,6 +499,11 @@ class Command(object): > > > properly routed to LLDB frontend. Any unhandled exception will be > > > automatically transformed into proper errors. > > > """ > > > + def invoke(self, arg, from_tty): > > > + try: > > > + self.execute(arg) > > > + except Exception as e: > > > + dbg.write(e) > > > > Why do we need this change? > > > > The error message for such situation is changed and non informative: > > > > | Breakpoint 1, lj_cf_dofile (L=0x2) at /home/burii/reviews/luajit/lj-dbg/src/lib_base.c:429 > > | 429 { > > | (gdb) lj-stack L > > | Python Exception : unsupported operand type(s) for +: 'MemoryError' and 'str' > > | Error occurred in Python: unsupported operand type(s) for +: 'MemoryError' and 'str' > > > > Within the following implementation all works as expected. > > | def invoke(self, arg, from_tty): > > | self.execute(arg) > Fixed. Sorry, but I see no related changes, and the old error message is still persisted. > > > > This produces more understandable reason of an error: > > | (gdb) lj-stack L > > | Python Exception : Cannot access memory at address 0x26 > > | Error occurred in Python: Cannot access memory at address 0x26 > > > Without the explicit exception output LLDB command just fails silently. > Choosing from a less readable error and not understanding what happened > (and whether it even happened at all) I would personally prefer the > first option. So, this case should be handled specially for the lldb provider? -- Best regards, Sergey Kaplun