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 C2C1413E49A; Thu, 1 Dec 2022 15:31:15 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C2C1413E49A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1669897875; bh=/lKEAyPgCUu+xJ6xz3HCjgPwG/PjKphwl9AjDVWmcno=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=DNY7SqXI2006USWr8UeFe6vtmACNMS2gQtwaevgasvPefY6Q04Uye/XjiKqmxj3DO rREmD8EoBDbHQ9a9wN4vsdn9GUgz42dqjcv4gatx2PK7EtSYzVELCLayUpFKf7Sv3J vS2eLvZr+ESUzl5g+Pw6wY5EPzMh7jVOiT0lokyo= Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (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 3A5FB350B8 for ; Thu, 1 Dec 2022 15:31:14 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3A5FB350B8 Received: by smtp45.i.mail.ru with esmtpa (envelope-from ) id 1p0iif-0006QI-F6; Thu, 01 Dec 2022 15:31:14 +0300 Date: Thu, 1 Dec 2022 15:28:01 +0300 To: Maxim Kokryashkin , Maksim Kokryashkin , tarantool-patches@dev.tarantool.org Message-ID: References: <20221028092638.11506-1-max.kokryashkin@gmail.com> <20221028092638.11506-9-max.kokryashkin@gmail.com> <1669814478.236264054@f547.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD908190A22B884CF14CD3D33834FD67854335A9BD4327CD189182A05F538085040C73B04217DCEA47EB3D61647AC9A2C12C1ED05745B85F21B837AED8DB850D436 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F09446BC3D835A58EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063776672C316918EFDB8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8722552859C562FE694C91C195AAFF098117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC47272755C61AA17BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520CCD848CCB6FE560CE5D25F19253116ADD2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE042285CD7A5C321F7B089FF177BE8049D8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3F8BD4E506CFA3D882D242C3BD2E3F4C6C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F79006376A91CFDE938F542CEFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3444047AE358B40754D609BCCABEA60FA3FC2FD9FC0138D250F74976491F1545249B648BFB3BE3A1471D7E09C32AA3244CFAE93B32DBF922A282C94E2D3AB69865CE0B41342B755BCDFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojWg9qwXN3O9VzXG/hMrHU/w== X-Mailru-Sender: F6248FDC0389C5118060C76C4E47A9E095F9BF158D4283F58DA6E7BB9567D2EDB7CBEF92542CD7C88B0A2698F12F5C9EC77752E0C033A69E86920BD37369036789A8C6A0E60D2BB63A5DB60FBEB33A8A0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v4 8/8] OSX/ARM64: Fix external unwinding. 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, again! On 01.12.22, Sergey Kaplun via Tarantool-patches wrote: > Hi, thanks for the explanations! > LGTM, then. > > On 30.11.22, Maxim Kokryashkin wrote: > > > > Hi! > > Thanks for the review! > >   > > >  > > >>Hi, Maksim! > > >> > > >>Thanks for the patch! > > >> > > >>LGTM, but I have a bunch of questions to clarify it. > > >> > > >>On 28.10.22, Maksim Kokryashkin wrote: > > >>> Contributed by Edmund Kapusniak. For more info, > > >>> see #698 and #757. > > >>> > > >>> (cherry picked from commit c38747b626b978555324504ec29a110f6b04902f) > > >>> > > >>> To allow compiler generate compact unwind info generation > > >>> for Mach-O, fp must point to the saved fp, and the frame > > >>> must be specified relative to fp+16. > > >> > > >>Is there any link to documentation or source code to inspect this > > >>behaviour? > > >Unfortunately, there are no official docs for that. However, there is > > >a community effort to create one here[1]. Also, this header file from > > >the Apple’s sources is quite useful. Added both of them to commit > > >message for those who will get the masculine urge to dive into this. > > Meh, not much info about it in the mentioned doc. > > I suppose that aarch64 ABI requires to save fp and lr by analog with arm > arch. See the following comment for arm (unfortunately, there is no such > comment for aarch64). > https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm.h#L812 > > But I'm still struggling to find some relative docs about it. > > > >> > > >>> ELF unwind info has > > >>> been updated to also use fp+16 rather than sp+CFRAME_SIZE. > > >> > > > > > >>> Offset to pointer to personality routine specified as @GOT-. rather > > >>> than @GOTPCREL. > > >> > > >>Does it mean that we use incorrect encoded offset (I see encoding for > > >>offset is still the same) for our personality routine? > > >>If so, maybe the other changes are just refactoring? > > >No, that is not correct. Offset has changed, because any  > > >`func@GOT` expression is translated into offset. > > >Moreover, I doubt it is possible to fill in offset to GOT by hand. > > >What goes after the pointer to the personality routine > > >is LSDA, according to the Apple’s source[2]. @GOTPCREL and @GOT > > >are interchangeable most of the time, except for the cases when signed > > >32-bit RIP references are not enough for you, which seems to be the case here. > > So, GOTPCREL allows you to "recalculate" reference to a function to > 32-bit value and use it? Do I get the idea correct? Yes, this is the issue mentioned here: https://github.com/LuaJIT/LuaJIT/issues/698#issuecomment-841645665 And usage of @GOT-. fixes the build for M1. > > > >> > > >>> > > >>> Re-enabled LUAJIT_UNWIND_EXTERNAL by default on OSX. > > >>> > > >>> Maxim Kokryashkin: > > >>> * added the description for the issue and the test > > >>> > > >>> Resolves tarantool/tarantool#6096 > > >>> Part of tarantool/tarantool#7230 > > >>> --- > > > > > >[1]:  https://faultlore.com/blah/compact-unwinding/#unwinding-tables-dwarf-cfi > > >[2]:  https://opensource.apple.com/source/libunwind/libunwind-35.3/include/mach-o/compact_unwind_encoding.h > > >-- > > >Best regards, > > >Maxim Kokryashkin > > >  > > -- > Best regards, > Sergey Kaplun -- Best regards, Sergey Kaplun