From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 998047030C; Mon, 24 May 2021 16:30:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 998047030C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1621863048; bh=k9ym0QwTIXhVscG1KAQ5+pCpdYRc4rggDWegyWuW0Rg=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=wGG7EKxf8Z6jkUVDEDjKiJpz84bktN2jlrUmSBCQR4OcG3A4fDPtegbsbGhZO7HgM 4MqOqhXCsSqbeEf9LJrRsnZKw19xjRrEYiOtAVFhkbWw1EUntJHDq5LQFSnZC4ZTWk iwpb7f9VRtKUOaRiBtx03hX60RoT/PxLQgN5ArbM= Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 17DA974144 for ; Mon, 24 May 2021 16:28:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 17DA974144 Received: by smtp29.i.mail.ru with esmtpa (envelope-from ) id 1llAdU-0002uA-8e; Mon, 24 May 2021 16:28:48 +0300 To: Igor Munkin , Sergey Ostanevich Date: Mon, 24 May 2021 16:27:33 +0300 Message-Id: X-Mailer: git-send-email 2.31.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD91B019B01C53E51AFA94C0B24B2C939D4C80F0683D6F6F7C600894C459B0CD1B93E8C21F87D6790157914F338E18ECD0315943EE8DFA7CAB93DBFFC9DE3409321 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7922D113DFDC6D5A3EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637DB576DCB83B448D28638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D88A5B3CFE31DF360B491131B5C2816381117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCAE9A1BBD95851C5BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751F618001F51B5FD3F9D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6A1DCCEB63E2F10FB089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: C20DE7B7AB408E4181F030C43753B8186998911F362727C4C7A0BC55FA0FE5FCC52230DFBDD32B7388A96A28A1ED025BAFC42A8A945567FFB1881A6453793CE9C32612AADDFBE061C61BE10805914D3804EBA3D8E7E5B87ABF8C51168CD8EBDB1A9C11735BBA05FBDC48ACC2A39D04F89CDFB48F4795C241BDAD6C7F3747799A X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34FD9114F69CA58D1E8A5B7D74FF2D466117E495A8197EB06FC6D52CE110A8D3AA73896553B9CF5F1C1D7E09C32AA3244C68BBB300095D4FEDC81F5E8EB9CA4130A995755A1445935E927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojbL9S8ysBdXhAIdl7nGLKX6UdcLkHr9vF X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB4EAA3C9F8185256EF1177EFA429EB51CFA76E30A15913CC6AF2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: [Tarantool-patches] [PATCH luajit 4/4] ARM64: Fix xpcall() error case (really). X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" From: Mike Pall Thanks to François Perrad and Stefan Pejic. (cherry picked from commit d417ded17945b4211608d497d50b509e0274f5e0) Premature decrementing VM's RC register before switch to fff_fallback handler during processing `xpcall()` fast function leads to incorrect stack layout (not enough arguments on stack), when `xpcall()` calls without a second argument or if it is not a function (see <301-basic.t> test in lua-Harness test suite). While further error processing it leads to incorrect error message, due to stack inconsistency. This patch stores intermediate result into TMP1 register (it does not determine fallback's behaviour and there is no way to return from fallback back to xpcall processing with spoiled TMP1) and moves RC setting after possible switching to fallback handler. Sergey Kaplun: * added the description for the problem Resolves tarantool/tarantool#6093 Part of tarantool/tarantool#5629 --- src/vm_arm64.dasc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/vm_arm64.dasc b/src/vm_arm64.dasc index e16a77ab..6e298255 100644 --- a/src/vm_arm64.dasc +++ b/src/vm_arm64.dasc @@ -1183,7 +1183,7 @@ static void build_subroutines(BuildCtx *ctx) |.ffunc xpcall | ldp CARG1, CARG2, [BASE] | ldrb TMP0w, GL->hookmask - | subs NARGS8:RC, NARGS8:RC, #16 + | subs NARGS8:TMP1, NARGS8:RC, #16 | blo ->fff_fallback | mov RB, BASE | asr ITYPE, CARG2, #47 @@ -1191,6 +1191,7 @@ static void build_subroutines(BuildCtx *ctx) | cmn ITYPE, #-LJ_TFUNC | add PC, TMP0, #24+FRAME_PCALL | bne ->fff_fallback // Traceback must be a function. + | mov NARGS8:RC, NARGS8:TMP1 | add BASE, BASE, #24 | stp CARG2, CARG1, [RB] // Swap function and traceback. | cbz NARGS8:RC, ->vm_call_dispatch -- 2.31.0