debug.getlocal from within return hook

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

debug.getlocal from within return hook

Philipp Janda
Hi!

Is it supported to enumerate/query the local variables of a function
from within a return hook?

I have some difficulties on all Lua versions since 5.1:

Lua 5.1:

     func a 10
     func b table: 0x18338e0
     func c function: 0x182e890
     func d true
     func e string

(apparently all locals are already gone).

Lua 5.2:

     func a 10
     func b table: 0x1b3ed10
     func c function: 0x1b3f4c0
     func d true
     func e string

     HOOK a table: 0x1b3fbc0
     HOOK b function: 0x1b3c850
     HOOK c 3
     HOOK d c
     HOOK e c

(local variable names are still there, values are wrong)

Lua 5.3:

     func a 10
     func b table: 0x8fbc80
     func c function: 0x8fbcc0
     func d true
     func e string

     HOOK a table: 0x8f77b0
     HOOK b function: 0x8f7590
     HOOK c 3
     HOOK d c
     HOOK e c

(same as 5.2)

LuaJIT seems to manage:

     func a 10
     func b table: 0x40622d08
     func c function: 0x4061f780
     func d true
     func e string

     HOOK a 10
     HOOK b table: 0x40622d08
     HOOK c function: 0x4061f780
     HOOK d true
     HOOK e string

Test script attached.

For now I'll probably try to use the line hook, discarding the results
of all calls except the last for each function.

Thx,
Philipp


locals.lua (689 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

彭 书呆
在 2015/5/19 0:32, Philipp Janda 写道:
> Hi!
>
> Is it supported to enumerate/query the local variables of a function from within a return hook?
>

local variables are scoped; as I understand, the when the return hook get called, it still _within_ the
returning function. the manual says [http://www.lua.org/manual/5.3/manual.html#lua_sethook]:

   The return hook:  is called when the interpreter returns from a function.
                     The hook is called *just before* Lua leaves the function.
                     There is no standard way to access the values to be returned by the function.

> I have some difficulties on all Lua versions since 5.1:
>
> Lua 5.1:
>
>     func    a    10
>     func    b    table: 0x18338e0
>     func    c    function: 0x182e890
>     func    d    true
>     func    e    string
>
> (apparently all locals are already gone).
>
> Lua 5.2:
>
>     func    a    10
>     func    b    table: 0x1b3ed10
>     func    c    function: 0x1b3f4c0
>     func    d    true
>     func    e    string
>
>     HOOK    a    table: 0x1b3fbc0
>     HOOK    b    function: 0x1b3c850
>     HOOK    c    3
>     HOOK    d    c
>     HOOK    e    c
>
> (local variable names are still there, values are wrong)
>
> Lua 5.3:
>
>     func    a    10
>     func    b    table: 0x8fbc80
>     func    c    function: 0x8fbcc0
>     func    d    true
>     func    e    string
>
>     HOOK    a    table: 0x8f77b0
>     HOOK    b    function: 0x8f7590
>     HOOK    c    3
>     HOOK    d    c
>     HOOK    e    c
>
> (same as 5.2)
>
> LuaJIT seems to manage:
>
>     func    a    10
>     func    b    table: 0x40622d08
>     func    c    function: 0x4061f780
>     func    d    true
>     func    e    string
>
>     HOOK    a    10
>     HOOK    b    table: 0x40622d08
>     HOOK    c    function: 0x4061f780
>     HOOK    d    true
>     HOOK    e    string
>
> Test script attached.
>

I checked the attached script and examined the source code of Lua.
interestingly, if you return something (even `nil') instead of nothing from that function,
you'll get the expected result (I have Lua 5.2 installed, but I believe it applies to 5.3):

--------------------------
   func    a       10
   func    b       table: 000000000052BB20
   func    c       function: 000000000052CDE0
   func    d       true
   func    e       string

   HOOK    a       10
   HOOK    b       table: 000000000052BB20
   HOOK    c       function: 000000000052CDE0
   HOOK    d       true
   HOOK    e       string
---------------------------

for me, it feels like a bug (or call it a glitch) of Lua in this special situation.
I'll explain it in detail.

Lua calls the debug hook in function `luaD_poscall' (ldo.c), which is called by the VM
when executing the OP_RETURN instruction (lvm.c). but the OP_RETURN instruction will first
adjust the stack, according to the returning values.
this is all good, except when the function returns NOTHING, in which case the RA register
of OP_RETURN is 0, so the VM simply empty the the (still semantically active) stack frame.
thus you actually get values probably located in the stack frame of the hook itself
when you call debug.getlocal.


when the function returns NOTHING (either an explicit `return' statement or implicitly),
Lua generate this opcode:

   RETURN 0 1

when the function returns some value (e.g. nil), Lua generate this opcode:

   LOADNIL 8 0
   RETURN 8 2

in the latter case, the VM still adjust the stack before calling the return hook, but since
the returnning values are loaded at the top of the stack, the active stack frame holding the
local variables is not destroyed, so your hook can now get the expected results.

> For now I'll probably try to use the line hook, discarding the results of all calls except the last for each function.
>
see the workaround I mentioned above.

> Thx,
> Philipp
>

--
the nerdy Peng / 书呆彭 / Sent from Thunderbird



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Dirk Laurie-2
2015-05-19 7:50 GMT+02:00 "书呆彭, Peng Yi" <[hidden email]>:

> 在 2015/5/19 0:32, Philipp Janda 写道:
>>
>> Hi!
>>
>> Is it supported to enumerate/query the local variables of a function from
>> within a return hook?
>>
>
> local variables are scoped; as I understand, the when the return hook get
> called, it still _within_ the
> returning function. the manual says
> [http://www.lua.org/manual/5.3/manual.html#lua_sethook]:
>
>   The return hook:  is called when the interpreter returns from a function.
>                     The hook is called *just before* Lua leaves the
> function.
>                     There is no standard way to access the values to be
> returned by the function.
>
>
>> I have some difficulties on all Lua versions since 5.1:
>>
>> Lua 5.1:
>>
>>     func    a    10
>>     func    b    table: 0x18338e0
>>     func    c    function: 0x182e890
>>     func    d    true
>>     func    e    string
>>
>> (apparently all locals are already gone).
>>
>> Lua 5.2:
>>
>>     func    a    10
>>     func    b    table: 0x1b3ed10
>>     func    c    function: 0x1b3f4c0
>>     func    d    true
>>     func    e    string
>>
>>     HOOK    a    table: 0x1b3fbc0
>>     HOOK    b    function: 0x1b3c850
>>     HOOK    c    3
>>     HOOK    d    c
>>     HOOK    e    c
>>
>> (local variable names are still there, values are wrong)
>>
>> Lua 5.3:
>>
>>     func    a    10
>>     func    b    table: 0x8fbc80
>>     func    c    function: 0x8fbcc0
>>     func    d    true
>>     func    e    string
>>
>>     HOOK    a    table: 0x8f77b0
>>     HOOK    b    function: 0x8f7590
>>     HOOK    c    3
>>     HOOK    d    c
>>     HOOK    e    c
>>
>> (same as 5.2)
>>
>> LuaJIT seems to manage:
>>
>>     func    a    10
>>     func    b    table: 0x40622d08
>>     func    c    function: 0x4061f780
>>     func    d    true
>>     func    e    string
>>
>>     HOOK    a    10
>>     HOOK    b    table: 0x40622d08
>>     HOOK    c    function: 0x4061f780
>>     HOOK    d    true
>>     HOOK    e    string
>>
>> Test script attached.
>>
>
> I checked the attached script and examined the source code of Lua.
> interestingly, if you return something (even `nil') instead of nothing from
> that function,
> you'll get the expected result (I have Lua 5.2 installed, but I believe it
> applies to 5.3):
>
> --------------------------
>   func    a       10
>   func    b       table: 000000000052BB20
>   func    c       function: 000000000052CDE0
>   func    d       true
>   func    e       string
>
>   HOOK    a       10
>   HOOK    b       table: 000000000052BB20
>   HOOK    c       function: 000000000052CDE0
>   HOOK    d       true
>   HOOK    e       string
> ---------------------------
>
> for me, it feels like a bug (or call it a glitch) of Lua in this special
> situation.
> I'll explain it in detail.
>
> Lua calls the debug hook in function `luaD_poscall' (ldo.c), which is called
> by the VM
> when executing the OP_RETURN instruction (lvm.c). but the OP_RETURN
> instruction will first
> adjust the stack, according to the returning values.
> this is all good, except when the function returns NOTHING, in which case
> the RA register
> of OP_RETURN is 0, so the VM simply empty the the (still semantically
> active) stack frame.
> thus you actually get values probably located in the stack frame of the hook
> itself
> when you call debug.getlocal.
>
>
> when the function returns NOTHING (either an explicit `return' statement or
> implicitly),
> Lua generate this opcode:
>
>   RETURN 0 1
>
> when the function returns some value (e.g. nil), Lua generate this opcode:
>
>   LOADNIL 8 0
>   RETURN 8 2
>
> in the latter case, the VM still adjust the stack before calling the return
> hook, but since
> the returnning values are loaded at the top of the stack, the active stack
> frame holding the
> local variables is not destroyed, so your hook can now get the expected
> results.

Something else that may also be relevant: Lua always generates an empty
return even when you have other returns, but it is not reached if you
have enough real returns. Maybe it is only when you execute that empty
return that the problem arises. I.e. an explicit return nothing higher up
may still be OK. I don't have the time to try it out right now.

Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Philipp Janda
In reply to this post by 彭 书呆
Hi!

Am 19.05.2015 um 07:50 schröbte "书呆彭, Peng Yi":
>
> I checked the attached script and examined the source code of Lua.
> interestingly, if you return something (even `nil') instead of nothing
> from that function,
> you'll get the expected result (I have Lua 5.2 installed, but I believe
> it applies to 5.3):

Thanks very much! I can confirm that a single explicit return value
fixes the behavior of the test script on Lua 5.1, 5.2, and 5.3 (an empty
`return` is insufficient). Unfortunately, in my original code where I
encountered the problem I already had an explicit return value (and it
still doesn't work except on LuaJIT). I'll try to come up with an
updated test case.

In the meantime I have come across another case of inconsistent behavior
while implementing my line hook workaround (this one I can definitely
fix with an explicit return -- or any extra statement for that matter):

If I have a chunk that consists entirely of local function definitions
(using the syntax sugar) I can't get the last local variable from within
the line hook (this can actually be explained via the manual since the
line hook is called *before* a line is evaluated). However, if I don't
use the syntax sugar but `local x; function x() end` instead, then I
*can* get that last local. Also if I use normal functions instead of
chunks, I can get the last local no matter what syntax I use. This
applies to Lua 5.2, 5.3, and LuaJIT (Lua 5.1 is more consistent and I
never get the last local).

Test script is attached, here is the output for Lua 5.2 (notice how the
`y` variable from `func1` is missing):

     func1 x function: 0x18a2ef0

     func2 x function: 0x189e560
     func2 x function: 0x189e560
     func2 y nil
     func2 x function: 0x189e560
     func2 y nil
     func2 x function: 0x189e560
     func2 y function: 0x18a2060

     func3 x function: 0x18a18d0
     func3 x function: 0x18a18d0
     func3 y function: 0x18a1a20

     func4 x function: 0x18a0ff0
     func4 x function: 0x18a0ff0
     func4 y nil
     func4 x function: 0x18a0ff0
     func4 y nil
     func4 x function: 0x18a0ff0
     func4 y function: 0x18a11f0


Thanks again,
Philipp



lhook.lua (928 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Philipp Janda
Hi!

Am 19.05.2015 um 10:33 schröbte Philipp Janda:
>
> Thanks very much! I can confirm that a single explicit return value
> fixes the behavior of the test script on Lua 5.1, 5.2, and 5.3 (an empty
> `return` is insufficient). Unfortunately, in my original code where I
> encountered the problem I already had an explicit return value (and it
> still doesn't work except on LuaJIT). I'll try to come up with an
> updated test case.

As promised here the updated test case. Interestingly, which local
variables get garbled depends on which local variable I return
(unfortunately the original code is primarily used on module chunks
where I often return the first local I define (`local M = {}`)) ...

Output (variable `b` is returned from `func`):

     func a 10
     func b table: 0x11b3da0
     func c function: 0x11b4200
     func d true
     func e string

     HOOK a 10
     HOOK b table: 0x11b3da0
     HOOK c table: 0x11af7b0
     HOOK d function: 0x11af590
     HOOK e 5


Philipp



locals2.lua (701 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Roberto Ierusalimschy
In reply to this post by 彭 书呆
> I checked the attached script and examined the source code of Lua.
> [...]
> when the function returns NOTHING (either an explicit `return' statement or implicitly),
> Lua generate this opcode:
>
>   RETURN 0 1
>
> when the function returns some value (e.g. nil), Lua generate this opcode:
>
>   LOADNIL 8 0
>   RETURN 8 2
>
> in the latter case, the VM still adjust the stack before calling the return hook, but since
> the returnning values are loaded at the top of the stack, the active stack frame holding the
> local variables is not destroyed, so your hook can now get the expected results.

Many thanks for that detailed analysis. (BTW, as Philipp already found
out, the problem also happens when we return a local variable, because
Lua optimizes that case and returns the variable directly from where it
lives, not from the top of the stack.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

彭 书呆
In reply to this post by Philipp Janda
在 2015/5/19 16:50, Philipp Janda 写道:

> Hi!
>
> Am 19.05.2015 um 10:33 schröbte Philipp Janda:
>>
>> Thanks very much! I can confirm that a single explicit return value
>> fixes the behavior of the test script on Lua 5.1, 5.2, and 5.3 (an empty
>> `return` is insufficient). Unfortunately, in my original code where I
>> encountered the problem I already had an explicit return value (and it
>> still doesn't work except on LuaJIT). I'll try to come up with an
>> updated test case.
>
> As promised here the updated test case. Interestingly, which local variables get garbled depends on which local variable I return (unfortunately the original code is primarily used on module chunks where I often return the first local I define (`local M = {}`)) ...
>

as Roberto said, it is due to an optimization in the opcode generator.
before Lua changes(or should I say fixes?) this inconsistent hook behavior,
you can use a simple workaround: just reserve a new stack slot and copy the
to-be-returned local variable there, then return the new one.

in your test script, it is something like:

-------------------------------------
   local function func ()
     local a, b, c, d, e = <...>
     <...>
     local __ret = b
     return __ret
   end
-------------------------------------

--
the nerdy Peng / 书呆彭 / Sent from Thunderbird



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Philipp Janda
Am 20.05.2015 um 07:24 schröbte "书呆彭, Peng Yi":

>
> as Roberto said, it is due to an optimization in the opcode generator.
> before Lua changes(or should I say fixes?) this inconsistent hook behavior,
> you can use a simple workaround: just reserve a new stack slot and copy the
> to-be-returned local variable there, then return the new one.
>
> in your test script, it is something like:
>
> -------------------------------------
>    local function func ()
>      local a, b, c, d, e = <...>
>      <...>
>      local __ret = b
>      return __ret
>    end
> -------------------------------------

Thanks again, but I will probably use a line-hook for now. I'd like to
avoid parsing Lua files of possibly different Lua versions and patching
their source code. I can't see an easy and reliable way to do that
automatically.

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Dirk Laurie-2
2015-05-20 8:17 GMT+02:00 Philipp Janda <[hidden email]>:

> I'd like to avoid parsing Lua files of possibly different Lua versions and
> patching their source code.

One could argue that by definition a program with debug hooks in it
is still under development, and changes to its source code are still
to be expected.

What I have learnt from this thread is "return hooks give undefined
results when an expression rather than a variable is being returned".
I think I'll patch it into my local copy of $LUA/doc/manual.html.

Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

彭 书呆
In reply to this post by Philipp Janda
在 2015/5/19 16:33, Philipp Janda 写道:
>
> In the meantime I have come across another case of inconsistent behavior while implementing my line hook workaround (this one I can definitely fix with an explicit return -- or any extra statement for that matter):
>
> If I have a chunk that consists entirely of local function definitions (using the syntax sugar) I can't get the last local variable from within the line hook (this can actually be explained via the manual since the line hook is called *before* a line is evaluated). However, if I don't use the syntax sugar but `local x; function x() end` instead, then I *can* get that last local. Also if I use normal functions instead of chunks, I can get the last local no matter what syntax I use. This applies to Lua 5.2, 5.3, and LuaJIT (Lua 5.1 is more consistent and I never get the last local).
>

it is nothing to do with whether you use the "chunk loading" way or "function definition" way.
try this (note the subtle difference from your func1 & func3. explanation follows):

-------------------------------------------
   local func5 = (loadstring or load)[[
     local function x()
     end
     local function y()
     end
     ;
   ]]
   local func6 = function ()
     local function x()
     end
     local function y()
     end end
-------------------------------------------


detailed explanation:

it is due to the way how the VM decides whether to call a line hook: the VM execute
a Lua function instruction(i.e. VM OPCODE) by instruction, not line by line.
it uses the debug info to "guess" which line is the "current line". before executing
an instruction, the VM checks if the line number value of the to-be-executed instruction
is different from the line number of the last-executed instruction. if so,the line hook
should be called.

in your test script, func1 and func3 actually have identical instruction sequences,
but the line number info are different. by using `string.dump` function, and
the `luac -l` command, you can see the listings of the functions:

=============== listing of func1 =================
main <(string):0,0> (3 instructions at 0000000000818060)
0+ params, 2 slots, 1 upvalue, 2 locals, 0 constants, 2 functions
     1    [2]    CLOSURE      0 0    ; 00000000008180F0
     2    [4]    CLOSURE      1 1    ; 0000000000818210
     3    [4]    RETURN       0 1
constants (0) for 0000000000818060:
locals (2) for 0000000000818060:
     0    x    2    4
     1    y    3    4
upvalues (1) for 0000000000818060:
     0    _ENV    1    0
===================================================

================ listing of func3 =================
function <lhook.lua:15,20> (3 instructions at 0000000000658060)
0 params, 2 slots, 0 upvalues, 2 locals, 0 constants, 2 functions
     1    [17]    CLOSURE      0 0    ; 00000000006580F0
     2    [19]    CLOSURE      1 1    ; 0000000000658180
     3    [20]    RETURN       0 1
constants (0) for 0000000000658060:
locals (2) for 0000000000658060:
     0    x    2    4
     1    y    3    4
upvalues (0) for 0000000000658060:
====================================================

see the line number difference? note the RETURN instruction at the end.
(the _ENV upvalue is irrelevant with this line hook subject)

how come that difference?

Lua always generate an RETURN instruction no matter whether there is an
explicit return statement. the parser emits this instruction at the end
of a function.

for func1, it is the EOS token that finish the function definition.
when the parser sees the EOS token, it emit the RETURN instruction and
put the line number to the debug info. the lexer does not update the line
number for the EOS token, thus the RETURN instruction has the same line number
of the previous CLOSURE instruction.

for func3, it is the `end` keyword that finish the function definition.
this time the lexer has the "correct" line number info for that token.

now I believe you know the difference between func1, func3 (and the above func5 & func6)


for func2 and func4, you can check the listings yourself.
they use 1 more stack slot and 2 more instructions than func1 & func3.
hint: you don't really _declare_ (uninitialized, like C) local variables in Lua.


p.s. in the hook function, you may print the function name and line number before
enumerating local variables, so that you can get a better impression about when and how
the hook is called.

> <...>
>
> Philipp
>
>

--
the nerdy Peng / 书呆彭 / Sent from Thunderbird



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

彭 书呆
In reply to this post by Roberto Ierusalimschy
在 2015/5/19 20:03, Roberto Ierusalimschy 写道:

>> I checked the attached script and examined the source code of Lua.
>> [...]
>> when the function returns NOTHING (either an explicit `return' statement or implicitly),
>> Lua generate this opcode:
>>
>>    RETURN 0 1
>>
>> when the function returns some value (e.g. nil), Lua generate this opcode:
>>
>>    LOADNIL 8 0
>>    RETURN 8 2
>>
>> in the latter case, the VM still adjust the stack before calling the return hook, but since
>> the returnning values are loaded at the top of the stack, the active stack frame holding the
>> local variables is not destroyed, so your hook can now get the expected results.
> Many thanks for that detailed analysis. (BTW, as Philipp already found
> out, the problem also happens when we return a local variable, because
> Lua optimizes that case and returns the variable directly from where it
> lives, not from the top of the stack.)
>
> -- Roberto
>

similar problem exists with tail call hook (I have Lua 5.2, didn't check 5.3).

I think this optimization for the opcode genrator is just fine.
it is the VM that causes the 'incorrect' behavior. the VM invalidates
the slots when they are by definition still alive.

actually I found it totally unnecessary to adjust the stack top pointer.
anyway `luaD_poscall` is doing the work of moving the return values
to the caller's frame, whether or not a hook is called.

--
the nerdy Peng / 书呆彭 / Sent from Thunderbird



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Philipp Janda
In reply to this post by Dirk Laurie-2
Am 20.05.2015 um 08:36 schröbte Dirk Laurie:
> 2015-05-20 8:17 GMT+02:00 Philipp Janda <[hidden email]>:
>
>> I'd like to avoid parsing Lua files of possibly different Lua versions and
>> patching their source code.
>
> One could argue that by definition a program with debug hooks in it
> is still under development, and changes to its source code are still
> to be expected.

The program doesn't have debug hooks in it, the debug hooks get
installed by a driver program (pretty much like a debugger). The idea is
to write test functions as local functions in the module, side by side
with normal functions. The rationale would be similar to documentation
tools like LDoc: it is supposedly easier to keep them in sync if they
are next to each other. Other advantages would be that you can test
internal functions without messing up the public interface of your
module. Also, if you don't run under the test driver program that
rescues the local test functions via the debug hook, they all vanish
without a trace.
Sure, I could do some arbitrary code transformations by hand (I have to
write the test functions anyway), but this is very error prone: if I
forget, some test functions will silently be skipped, and depending on
the number of tested modules I may not notice. It's even worse if other
people use this testing method, because they probably have no idea why
it isn't working.
Automatically patching the source code during loading on the other hand
would be feasible as long as the line number information doesn't change.
But I'd like to support multiple Lua versions and make the process at
least coworker-proof ...

>
> What I have learnt from this thread is "return hooks give undefined
> results when an expression rather than a variable is being returned".
> I think I'll patch it into my local copy of $LUA/doc/manual.html.

How did you come to that conclusion?! The issue of this thread
explicitly also applies if you return a local variable, and there is
nothing wrong with a return hook unless you want to query the local
variables of the function that is about to return.

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Roberto Ierusalimschy
In reply to this post by 彭 书呆
> actually I found it totally unnecessary to adjust the stack top pointer.
> anyway `luaD_poscall` is doing the work of moving the return values
> to the caller's frame, whether or not a hook is called.

Currently, the stack pointer is what tells `luaD_poscall` how many
values should be returned (all values from 'firstresult' up to the top).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

彭 书呆
在 2015/5/20 20:51, Roberto Ierusalimschy 写道:
>> actually I found it totally unnecessary to adjust the stack top pointer.
>> anyway `luaD_poscall` is doing the work of moving the return values
>> to the caller's frame, whether or not a hook is called.
> Currently, the stack pointer is what tells `luaD_poscall` how many
> values should be returned (all values from 'firstresult' up to the top).
>
> -- Roberto
>


maybe we could just pass that parameter explicitly, instead of multi-use
the stack pointer, and leave the stack pointer for the active frame.

   int luaD_poscall (lua_State *L, StkId firstresult, StkId lastresult);


--
the nerdy Peng / 书呆彭 / Sent from Thunderbird



Reply | Threaded
Open this post in threaded view
|

Re: debug.getlocal from within return hook

Roberto Ierusalimschy
> maybe we could just pass that parameter explicitly, instead of multi-use
> the stack pointer, and leave the stack pointer for the active frame.
>
>   int luaD_poscall (lua_State *L, StkId firstresult, StkId lastresult);

Yes, this is what I am considering.

-- Roberto