Re: [Tarantool-patches] [PATCH luajit v6 1/2] debug: generalized extension

[Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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:

<snipped>

> > > -
> > > -        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):
> >
> > <snipped>
> >
> > > @@ -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 <class 'TypeError'>: 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 <class 'gdb.MemoryError'>: 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?

<snipped>

-- 
Best regards,
Sergey Kaplun