From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jit-return-831-listarch-jit=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 50829 invoked by alias); 2 Aug 2015 09:48:17 -0000
Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:jit@gcc.gnu.org>
List-Help: <mailto:jit-help@gcc.gnu.org>
List-Subscribe: <mailto:jit-subscribe@gcc.gnu.org>
Sender: jit-owner@gcc.gnu.org
Received: (qmail 50794 invoked by uid 89); 2 Aug 2015 09:48:12 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2
X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-HELO: mail-yk0-f180.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:date:message-id:subject:from:to
         :content-type;
        bh=/q/U2uSAtE6aJ+QIBy1biTl3Ko+1dd4HJy2CB6aXfZM=;
        b=Ya0A9gO27F6oN4L87j6sAYqLSkCXZEYPDDbjFHm7EM3LZhoAwxHYsgfYGk7eLBNh3L
         eG12ChseKpVLmWZRFRUxwZ3uUaE+DZeiD1r6PLQ1zrMNrdB92NJVNi1IEFIt3OYVWpVM
         x3s5kS9x1rz3YwkkIxjJ6lqzzEI7HPDCB45qdmBpGjHpjodB58X6M18ntEaqitPlrevE
         J7AVvVoqkBkzK8kibgGc4OVqJezR+Vw4q/a90U6Ob1ZyD5UauJKV9nBlos1uKjUr8dUf
         C+DSYGsRfGmRurf5+XrirvlqUCDFCPBDHC2RhoDXjw6FQXHs8ozrMz5+FpgLNbWTGgfg
         qXow==
X-Gm-Message-State: ALoCoQnKDGSEKAJ8VxJlYfr5N2Jv13p5CuVYwUQKAhgFA5DJHeUkXZbjHX6fE3DRSgmkKTY/vFmp
MIME-Version: 1.0
X-Received: by 10.170.111.16 with SMTP id d16mr13870258ykb.29.1438508889121;
 Sun, 02 Aug 2015 02:48:09 -0700 (PDT)
Date: Thu, 01 Jan 2015 00:00:00 -0000
Message-ID: <CACXZuxdJ-wGcFjHi7KeDOrxL5wePApPXj9uxbrcr9QUDcPFwuQ@mail.gmail.com>
Subject: Ravi bug related to setting of L->top in OP_RETURN
From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: jit@gcc.gnu.org
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2015-q3/txt/msg00131.txt.bz2

Hi

I am investigating a particularly difficult bug related to setting of
L->top, and would appreciate some insight on what L->top should be
when a function returns via OP_RETURN.

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;

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.

The bug in Ravi is caused under following conditions:

JITed code invokes Lua function via luaV_execute() in a local variable
declaration:

local var = func(a,b)

Since CIST_REENTRY is not set in this case (whereas it would be if
interpreted Lua code had called the function) upon return, L->top is
not reset to ci->top although luaD_pocall returns non zero b. So this
then causes subsequent code to clobber the stack.

Thanks and Regards
Dibyendu