Re: Ravi bug related to setting of L->top in OP_RETURN

[Dibyendu Majumdar <mobile@...>]

On 5 August 2015 at 14:49, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> The Lua code does following in OP_RETURN:
>>
>>         int b = GETARG_B(i);
>>         if (cl->p->sizep > 0) luaF_close(L, base);
>>         b = luaD_poscall(L, ra, (b != 0 ? b - 1 : L->top - ra));
>>         if (!(ci->callstatus & CIST_REENTRY))  /* 'ci' still the called one */
>>           return;  /* external invocation: return */
>>         else {  /* invocation via reentry: continue execution */
>>           ci = L->ci;
>>           if (b) L->top = ci->top;
>>           lua_assert(isLua(ci));
>>           lua_assert(GET_OPCODE(*((ci)->u.l.savedpc - 1)) == OP_CALL);
>>           goto newframe;  /* restart luaV_execute over new Lua function */
>>         }
>>
>> It is not clear to me why in the external invocation case, if
>> following code is not executed:
>>
>>           ci = L->ci;
>>           if (b) L->top = ci->top;
>
> Both statements here prepare 'luaV_execute' to run the function
> "OP_RETURN" is returning *to*. (The previous call to 'luaD_poscall'
> already updated 'L->ci' to point to this previous entry.) When
> the running function (the one returning *from*) was called
> externally (e.g., from a C function), 'luaV_execute' returns,
> so this preparation would be meaningless.

Updating the variable 'ci' is meaningless but I don't see why the
setting of 'L->top' is also meaningless, given what you stated below.
Specially consider this:

When a Lua function is JIT compiled, this is equivalent roughly to
creating a custom version of luaV_execute(). So when a JITed Lua
function calls another JITed Lua function, it is equivalent to
invoking luaV_execute() for each Lua function. Therefore the
adjustment to 'L->top' is still required in this case?

It seems to me that there is an assumption that a Lua function will
never run another Lua function via luaV_execute() - that only C
functions can invoke luaV_execute()?

>
> When 'b' is zero, this return must return all values on the stack
> (e.g., 'return ...', and L->top must be kept for the next instruction
> (after the OP_CALL to where we are returning) to know how many
> results the function have (see next answer).
>
>
>> A related question is what is the meaning of the return value from
>> luaD_poscall() - it seems to be a signal for L-top to be reset to
>> ci->top, but I am not sure I understand when this happens.
>
> It happens when the function that called the one being returned needs
> multiple returns. As I explained, in that case L->top limits the
> number of values being returned, and will be corrected by the
> instruction following the OP_CALL (see comments in 'lopcdes.h').
>

Thanks - I will try to step through the code in light of above to
understand what I am missing.

Regards
Dibyendu