Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Kaplun <skaplun@tarantool.org>,
	Evgeniy Temirgaleev <e.temirgaleev@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit 0/4] Introduce dumpers for bytecodes in debuggers
Date: Fri, 5 Jun 2026 17:55:14 +0300	[thread overview]
Message-ID: <0396d6fa-a142-487c-b279-8cd6faa93b63@tarantool.org> (raw)
In-Reply-To: <20260604093052.2221827-1-skaplun@tarantool.org>

[-- Attachment #1: Type: text/plain, Size: 5938 bytes --]

Hi, Sergey,

thanks for your efforts in adding new functionality to dbg extension!

On 6/4/26 12:30, Sergey Kaplun wrote:
> Branch:https://github.com/tarantool/luajit/tree/skaplun/gh-4808-gco-func-proto-bytecode
> Issue:https://github.com/tarantool/tarantool/issues/4808
>
> This patch set allows you to inspect bytecodes for a single instruction,
> as well as for all bytecodes inside a function or its prototype via GDB
> and LLDB.
>
> The first patch is a fixup for the LLDB indexing negative values. It may
> affect the lj-stack command. The second patch fixes the DUALNUM mode
> detection in LLDB. These fixes are required for the last patch in the
> series.
>
> The third auxiliary patch is needed to introduce dumpers for GC objects
> similar to TValues dumpers. Also, it may be useful during different
> debugging scenarios, so it introduces the lj-gco <GCobj *> command to
> dump the GC object info in the same format as for a TValue slot.
>
> The last patch introduces 3 new commands:
> * lj-bc <GCIns *> -- dump single bytecode instruction
> * lj-func <GCfunc *> -- dump all bytecode instructions for Lua function
>    or report type of C or F function
> * lj-proto <GCproto *> -- dump all bytecode instructions for the
>    prototype
>
> For example, we have the following Lua script named <tmp.lua>:
it is worth adding this example to the appropriate commit message. What 
do you think?
> | 1 local function mywhile(a)
> | 2 	local r = 0
> | 3 	print(a)
> | 4 	while (a < 30) do
> | 5 		r = r + a * r/2
> | 6 	end
> | 7 	return r
> | 8 end
> | 9
> | 10 local uvname1 = false
> | 11 local uvname2 = false
> | 12 local function myif(a)
> | 13 	local s1 = a + 4
> | 14 	local s2 = s1 + 4
> | 15 	uvname1 = "s10"
> | 16 	uvname2 = "s11"
> | 17 	print(a)
> | 18 	if a > 10 then
> | 19 		return a + s2 + s1
> | 20 	else
> | 21 		return a - 10 - s2 - s1
> | 22 	end
> | 23 end
> | 24
> | 25 local f1 = myif
> | 26 local f2 = mywhile
> | 27 myif(12)
> | 28 mywhile(12)
>
> Assume we set a breakpoint at `lj_cf_print` (line 3).
> The lj-stack output contains the following lines:
>
> | 0x40001970            [    ] VALUE: Lua function @ 0x400083c0, 0 upvalues, "@../tmp.lua":1
> | 0x40001968            [    ] VALUE: Lua function @ 0x40002148, 2 upvalues, "@../tmp.lua":12
> | ...
> | 0x40001940            [    ] FRAME: [V] delta=1, Lua function @ 0x400084a0, 0 upvalues, "@../tmp.lua":0
>
> The first one is `myif()` function the second is `mywhile()` and the
> last one is function loaded via `dofile()`.
>
> The resulting output for the functions is the following:
>
> 1)
> | (gdb) lj-func 0x400083c0
> | "@../tmp.lua":1-8
> | 0000 FUNCF  rbase:   4
> | 0001 KSHORT dst:     1 lits:    0
> | 0002 GGET   dst:     2 str:     0 ; string "print" @ 0x400037f0
> | 0003 MOV    dst:     3 var:     0
> | 0004 CALL   base:    2 lit:     1 lit:     2
> | 0005 KSHORT dst:     2 lits:   30
> | 0006 ISGE   var:     0 var:     2
> | 0007 JMP    rbase:   2 jump:  => 0013
> | 0008 LOOP   rbase:   2 jump:  => 0013
> | 0009 MULVV  dst:     2 var:     0 var:     1
> | 0010 DIVVN  dst:     2 var:     2 num:     0 ; number 2
> | 0011 ADDVV  dst:     1 var:     1 var:     2
> | 0012 JMP    rbase:   2 jump:  => 0005
> | 0013 RET1   rbase:   1 lit:     2
>
> The report is the same as for the following command:
> | lj-proto (GCproto *)(((char *)(((GCfuncL *)0x400083c0)->pc.ptr32))-sizeof(GCproto))
>
> 2)
> | (gdb) lj-func 0x40002148
> | "@../tmp.lua":12-23
> | 0000 FUNCF  rbase:   5
> | 0001 ADDVN  dst:     1 var:     0 num:     0 ; number 4
> | 0002 ADDVN  dst:     2 var:     1 num:     0 ; number 4
> | 0003 USETS  uv:      0 str:     0 ; 0x40002527 "uvname1" ; string "s10" @ 0x40002298
> | 0004 USETS  uv:      1 str:     1 ; 0x4000252f "uvname2" ; string "s11" @ 0x400022b8
> | 0005 GGET   dst:     3 str:     2 ; string "print" @ 0x400037f0
> | 0006 MOV    dst:     4 var:     0
> | 0007 CALL   base:    3 lit:     1 lit:     2
> | 0008 KSHORT dst:     3 lits:   10
> | 0009 ISGE   var:     3 var:     0
> | 0010 JMP    rbase:   3 jump:  => 0015
> | 0011 ADDVV  dst:     3 var:     0 var:     2
> | 0012 ADDVV  dst:     3 var:     3 var:     1
> | 0013 RET1   rbase:   3 lit:     2
> | 0014 JMP    rbase:   3 jump:  => 0019
> | 0015 SUBVN  dst:     3 var:     0 num:     1 ; number 10
> | 0016 SUBVV  dst:     3 var:     3 var:     2
> | 0017 SUBVV  dst:     3 var:     3 var:     1
> | 0018 RET1   rbase:   3 lit:     2
> | 0019 RET0   rbase:   0 lit:     1
>
> 3)
>
> | (gdb) lj-func 0x400084a0
> | "@../tmp.lua":0-30
> | 0000 FUNCV  rbase:   8
> | 0001 FNEW   dst:     0 func:    0 ; "@../tmp.lua":1
> | 0002 KPRI   dst:     1 pri:     1
> | 0003 KPRI   dst:     2 pri:     1
> | 0004 FNEW   dst:     3 func:    1 ; "@../tmp.lua":12
> | 0005 MOV    dst:     4 var:     3
> | 0006 MOV    dst:     5 var:     0
> | 0007 MOV    dst:     6 var:     3
> | 0008 KSHORT dst:     7 lits:   12
> | 0009 CALL   base:    6 lit:     1 lit:     2
> | 0010 MOV    dst:     6 var:     0
> | 0011 KSHORT dst:     7 lits:   12
> | 0012 CALL   base:    6 lit:     1 lit:     2
> | 0013 UCLO   rbase:   0 jump:  => 0014
> | 0014 RET0   rbase:   0 lit:     1
>
> The single bytecode instruction may be useful when you debug the VM:
>
> | (gdb) b lj_BC_ISGE
> | Breakpoint 2 at 0x5555555f0a08
> | (gdb) c
> | Continuing.
> | Breakpoint 2, 0x00005555555f0a08 in lj_BC_ISGE ()
> | (gdb) lj-bc $rbx # PC refers __the next instruction__
> | JMP    rbase:   3 jump:  +5
> | (gdb) lj-bc ((BCIns *)$rbx) - 1 # current instruction
> | ISGE   var:     3 var:     0
>
>
> Sergey Kaplun (4):
>    dbg: fix lj-stack command for LLDB
>    dbg: fix DUALNUM detection for LLDB
>    dbg: introduce lj-gco command
>    dbg: introduce lj-bc, lj-func and lj-proto dumpers
>
>   src/luajit_dbg.py                             | 650 ++++++++++++++++--
>   .../debug-extension-tests.py                  | 203 +++++-
>   2 files changed, 757 insertions(+), 96 deletions(-)
>

[-- Attachment #2: Type: text/html, Size: 6546 bytes --]

  parent reply	other threads:[~2026-06-05 14:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-04  9:30 Sergey Kaplun via Tarantool-patches
2026-06-04  9:30 ` [Tarantool-patches] [PATCH luajit 1/4] dbg: fix lj-stack command for LLDB Sergey Kaplun via Tarantool-patches
2026-06-05 14:55   ` Sergey Bronnikov via Tarantool-patches
2026-06-04  9:30 ` [Tarantool-patches] [PATCH luajit 2/4] dbg: fix DUALNUM detection " Sergey Kaplun via Tarantool-patches
2026-06-05 14:57   ` Sergey Bronnikov via Tarantool-patches
2026-06-05 16:01     ` Sergey Kaplun via Tarantool-patches
2026-06-04  9:30 ` [Tarantool-patches] [PATCH luajit 3/4] dbg: introduce lj-gco command Sergey Kaplun via Tarantool-patches
2026-06-05 15:02   ` Sergey Bronnikov via Tarantool-patches
2026-06-04  9:30 ` [Tarantool-patches] [PATCH luajit 4/4] dbg: introduce lj-bc, lj-func and lj-proto dumpers Sergey Kaplun via Tarantool-patches
2026-06-05 15:07   ` Sergey Bronnikov via Tarantool-patches
2026-06-05 16:10     ` Sergey Kaplun via Tarantool-patches
2026-06-05 14:55 ` Sergey Bronnikov via Tarantool-patches [this message]
2026-06-05 16:03 ` [Tarantool-patches] [PATCH luajit 3/5] dbg: update help for the lj-arch command Sergey Kaplun via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0396d6fa-a142-487c-b279-8cd6faa93b63@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=e.temirgaleev@tarantool.org \
    --cc=sergeyb@tarantool.org \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit 0/4] Introduce dumpers for bytecodes in debuggers' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox