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 434196EC55; Thu, 22 Jul 2021 15:51:59 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 434196EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626958319; bh=WDoWVpKK1o4Lv7hEIPzDzECsgvKbzURwzDGW8tljxLE=; h=Date:In-Reply-To:To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZXFWYEg/xPLuYzEwq2lXzK1Ue/01i8bQd8s8lm6fVmUUA85BF8HQPrALtkuoVDAfR 5m1tFv00K1x2WZKFIbAK/tN5ym3q00tnHg6EjbJ5RO01HCWSic2M9zGk1AfL/OFVcD zklJTH6ZhDVlqNypqmA9vrSGCc3a//wIs649vtcU= Received: from smtp42.i.mail.ru (smtp42.i.mail.ru [94.100.177.102]) (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 EA2376EC55 for ; Thu, 22 Jul 2021 15:51:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EA2376EC55 Received: by smtp42.i.mail.ru with esmtpa (envelope-from ) id 1m6YBB-0005LR-0O; Thu, 22 Jul 2021 15:51:57 +0300 Message-Id: <08A03966-6DEA-4AE6-B962-0C3B2D436BFA@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_34612887-AFA5-41BF-8450-ABE551DF3358" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 22 Jul 2021 15:51:55 +0300 In-Reply-To: <20210722114821.GM11494@tarantool.org> To: Igor Munkin References: <20210618062234.871-1-skaplun@tarantool.org> <20210720122952.GH11494@tarantool.org> <20210721085411.GJ11494@tarantool.org> <3E1848F9-799D-4A38-9E7C-CD218ADFDF54@tarantool.org> <20210722114821.GM11494@tarantool.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C3A9514C5AE4B3B389A94BDFA06D40730D182A05F538085040D5B47D47AE01313D8B2D84661EBCA1373C85E3D42AAB8E3548968C1F83ABAD12 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7956F10FFCC7409BAEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375A514678F9DF65078638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D89F71CA41F1B5DE87679A9DB76472FE86117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751FE5D25F19253116ADD2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6AC294AFEFA671E80089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A531CC7AB720646CED9B682E38BBA07AB04B8DB4D98E901525D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7501A9DF589746230F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F0A5F58274334C95520147D901F9224B8DEF74B384E2462CDC0642644D80EC23522A4AE7250E75301D7E09C32AA3244C91700F142F1DE121B5E2D52C17DF27E964EE5813BBCA3A9DFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojaAaPr+N/4d1WyPhn2KKV2Q== X-Mailru-Sender: 3B9A0136629DC912F4AABCEFC589C81E03CC528A8CD1DDD7D7B4A93DD6B060C72A40E23960E69494AD07DD1419AC565FA614486B47F28B67C5E079CCF3B0523AED31B7EB2E253A9E112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v1] tools: fix luajit-gdb stack 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 Ostanevich via Tarantool-patches Reply-To: Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" --Apple-Mail=_34612887-AFA5-41BF-8450-ABE551DF3358 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Igor, Sure you can proceed with the push. Sergos. > On 22 Jul 2021, at 14:48, Igor Munkin wrote: >=20 > Sergos, >=20 > Thanks for your review! TL;DR: I would rather leave the patch with no > changes, but please consider my comments regarding your alternative > approach for iterating through the guest stack. >=20 > On 22.07.21, Sergey Ostanevich wrote: >> Hi! >>=20 >> Thanks for the patch! >>=20 >> I would rather remove all mentions of =E2=80=98bottom loop=E2=80=99 = as we named it at >> Intel. I'm not a big pro in python, still the =E2=80=98for=E2=80=99 = loop works fine=20 >> for me: >>=20 >> If we can unwind to the next frame - dump it (and further) >>=20 >>>>> s=3D[1] >>>>> for i in s: >> ... if (i=3D=3D1): >> ... s.append(2) >> ... continue >> ... print(i) >> ...=20 >> 2 >>=20 >> If it is the only one (dummy): >>=20 >>>>> s=3D[3] >>>>> for i in s: >> ... if (i=3D=3D1): >> ... s.append(2) >> ... continue >> ... print(i) >> ...=20 >> 3 >>=20 >> Does it make sense in this case? >=20 > Let's see what would we get for our case with guest stack unwinding. = The > algorithm is described by Sergey in the comment near the loop. But > imagine, we are iterating (backwards) through [L->stack, L-top] = segment > via for loop (as you suggest above). There is one condition to check > whether we have reached the bottom of the frame (dump framelink slot = and > continue the same way you showed above). However, we need one more > condition to skip the second slot for the framelink in LJ_FR2 mode. = As > a result we have a loop that iterates through the stack with at least > two conditions to skip some slots or dump them in other way. > Furthermore, your proposal leads to much more complex change in the > extension, comparing to those made by Sergey. >=20 > As I've already said, postcondition loop is the classic way for this > case. Moreover, I googled "how to emulate a do-while loop in Python?" > and the second option is unrolling the first iteration[1]. If one > wonders what is the first option -- use "while-true" loop with the > conditional break at the end. I equally hate both, so I'm OK with the > one chosen by Sergey. If you prefer "while-true", I believe Sergey can > rewrite this part, but considering your LGTM below, I guess you're OK > also with the current solution. So, I'll push the patch in a jiffy. >=20 >>=20 >> Anyways, it=E2=80=99s too much of nitpicking - LGTM in its current = version. >>=20 >> Regards, >> Sergos >>=20 >>=20 >=20 > >=20 >>=20 >=20 > [1]: https://stackoverflow.com/a/743186 = >=20 > --=20 > Best regards, > IM --Apple-Mail=_34612887-AFA5-41BF-8450-ABE551DF3358 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Igor,

Sure = you can proceed with the push.

Sergos.

On 22 = Jul 2021, at 14:48, Igor Munkin <imun@tarantool.org> wrote:

Sergos,

Thanks for your review! TL;DR: I would rather leave the patch = with no
changes, but = please consider my comments regarding your alternative
approach for = iterating through the guest stack.

On 22.07.21, Sergey Ostanevich wrote:
Hi!

Thanks for the patch!

I would rather remove all mentions of =E2=80=98bottom loop=E2=80= =99 as we named it at
Intel. I'm not a big pro in python, = still the =E2=80=98for=E2=80=99 loop works fine 
for me:

If we can unwind to the next frame - dump it = (and further)

s=3D[1]
for i in s:
...   if = (i=3D=3D1):
...     s.append(2)
...     continue
... =   print(i)
... 
2

If it is the only one (dummy):
s=3D[3]
for= i in s:
... =   if (i=3D=3D1):
... =     s.append(2)
... =     continue
... =   print(i)
... 
3

Does it make sense in this case?

Let's see what would we get for our case with guest stack = unwinding. The
algorithm is described by Sergey in the comment near the = loop. But
imagine, we = are iterating (backwards) through [L->stack, L-top] segment
via for loop = (as you suggest above). There is one condition to check
whether we = have reached the bottom of the frame (dump framelink slot and
continue the = same way you showed above). However, we need one more
condition to = skip the second slot for the framelink in LJ_FR2 mode. =  As
a result we = have a loop that iterates through the stack with at least
two = conditions to skip some slots or dump them in other way.
Furthermore, = your proposal leads to much more complex change in the
extension, = comparing to those made by Sergey.

As I've already said, postcondition loop is the classic way = for this
case. = Moreover, I googled "how to emulate a do-while loop in = Python?"
and the = second option is unrolling the first iteration[1]. If one
wonders what = is the first option -- use "while-true" loop with the
conditional = break at the end. I equally hate both, so I'm OK with the
one chosen by = Sergey. If you prefer "while-true", I believe Sergey can
rewrite this = part, but considering your LGTM below, I guess you're OK
also with the = current solution. So, I'll push the patch in a jiffy.


Anyways, it=E2=80=99s too much of nitpicking - LGTM in its = current version.

Regards,
Sergos



<snipped>



[1]: https://stackoverflow.com/a/743186

-- Best = regards,
IM

= --Apple-Mail=_34612887-AFA5-41BF-8450-ABE551DF3358--