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 BACDCC0A5E5; Tue, 23 Jul 2024 23:07:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org BACDCC0A5E5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1721765231; bh=Uvp0DWumbe8HJkTtw7FuPi//ALLWsSmpFvC3yG9GaAo=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=ru1JRNX4KJ+mAK5N2bkRXdvmUyezWZx4KttZeNESOGL/Kr+fdk/4Pzyott8qu7AdW YAgn3UcmrSaMVtkOE9oW2TqZXF4TEA/F6AR+E7HvNMykYH7zGDLbX2n9LcDwZRI9mC IndSIa69yf6poOIg52tXOtjTTT9etI65H4ZCUWj8= Received: from smtp17.i.mail.ru (smtp17.i.mail.ru [95.163.41.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id A772BC0A5E5 for ; Tue, 23 Jul 2024 23:07:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A772BC0A5E5 Received: by smtp17.i.mail.ru with esmtpa (envelope-from ) id 1sWLmv-0000000H7hk-0qeD; Tue, 23 Jul 2024 23:07:10 +0300 Content-Type: multipart/alternative; boundary="------------3oAgWQk8WsGXJJy8a0KmKOye" Message-ID: Date: Tue, 23 Jul 2024 23:07:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Sergey Kaplun Cc: Sergey Bronnikov , tarantool-patches@dev.tarantool.org References: <10ed208fcfacfa4c772f1cebe090595af3452ff3.1720182442.git.sergeyb@tarantool.org> <95ce34d1-234c-4e5c-a9a5-a62a5a5633e8@tarantool.org> In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD9DFBEF7BF43B4E757B6A573FB77D358D77D0E8DBACFCDBB68182A05F5380850404C228DA9ACA6FE27DCC707D8D557811A89CEA9C911D0999548F0FFC7BBA75C74103F86D185830D626F8F9941A8C2109B X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F09446BC3D835A58EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006379E90269B204C5E5D8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D838DA1D9F4E2554FA82A277CB005A93A30C0EB7E5515E58DCCC7F00164DA146DAFE8445B8C89999728AA50765F7900637F3E38EE449E3E2AE389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC821E93C0F2A571C7BF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA73AA81AA40904B5D9A18204E546F3947C86A7C529F68B8E5CC0837EA9F3D197644AD6D5ED66289B523666184CF4C3C14F6136E347CC761E07725E5C173C3A84C3E9BD6149E9909983BA3038C0950A5D36B5C8C57E37DE458B330BD67F2E7D9AF16D1867E19FE14079C09775C1D3CA48CF3D321E7403792E342EB15956EA79C166A417C69337E82CC275ECD9A6C639B01B78DA827A17800CE79E6B27D82EEA174F731C566533BA786AA5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A5F9150371A2B53F635002B1117B3ED696E4675BF909571B8B3E67C18142C611B7823CB91A9FED034534781492E4B8EEAD0CC187E7B980E3E7BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D34FDC9529E4578B99C91CA045801F6D3A4DA238CB5241E024B5198759557E2A96201A595EBD0CB6C951D7E09C32AA3244C75F6097F651F85D213EA5626864FADBF337F226E42949DD8EA455F16B58544A2557BDE0DD54B3590A5AE236DF995FB59978A700BF655EAEEED6A17656DB59BCAD427812AF56FC65B X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj49epkdzIowAR99cjIag5JQ== X-Mailru-Sender: C4F68CFF4024C8867DFDF7C7F25884585366D711E404ED376750B362712FA5BD9BDF2359610BA7FF6FC587E8459B3073645D15D82EE4B272BD6E4642A116CA93524AA66B5ACBE6721EF430B9A63E2A504198E0F3ECE9B5443453F38A29522196 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 2/2] OSX/iOS: Always generate 64 bit non-FAT Mach-O object files. 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 Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" This is a multi-part message in MIME format. --------------3oAgWQk8WsGXJJy8a0KmKOye Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Sergey thanks for the comments and fixes! But please don't squash fixes next time. Sergey On 11.07.2024 10:29, Sergey Kaplun wrote: > Hi, Sergey! > Thanks for the fixes! > I've applied some minor fixes to your branch. > LGTM, after adding the comment about ncmds value. > > On 10.07.24, Sergey Bronnikov wrote: >> Sergey, >> >> thanks for review. Fixes applied and force-pushed to the same branch. >> >> >> Sergey >> >> On 09.07.2024 16:03, Sergey Kaplun via Tarantool-patches wrote: >>> Hi, Sergey! >>> Thanks for the patch! >>> Please consider my comments below. >>> >>> May we add the test [1] to verify that there will be no regression in the >>> future? >> This "test" was for a FAT binary generated by LuaJIT. >> >> With backported patches, FAT (aka Universal Binary) support is gone. >> >> mach-O header is checked by tests in proposed patch. > OK, let's leave it as is. Thanks! > >>> On 05.07.24, Sergey Bronnikov wrote: >>>> Reported by Sergey Bronnikov. >>>> >>>> (cherry picked from commit 7110b935672489afd6ba3eef3e5139d2f3bd05b6) >>>> >>>> Previously, LuaJIT generated Mach-O FAT object files for ARM and >>>> ARM64 on macOS. The patch removes support of 32-bit ARM and >>>> FAT object files and now LuaJIT generate Mach-O object files for >>>> ARM64. >>> I suppose we should mention that no x86/x86_64 objects are generated >>> now. >> x86_64 is still there: >> >> $ ./build/gc64/src/luajit -b -o osx -a arm64 empty.lua empty.o >> $ file empty.o >> empty.o: Mach-O 64-bit arm64 object >> $ ./build/gc64/src/luajit -b -o osx -a x64 empty.lua empty.o >> $ file empty.o >> empty.o: Mach-O 64-bit x86_64 object >> $ > My bad, thanks for the clarification. > >> Anyway, commit message has been updated. >> >>>> Sergey Bronnikov: >>>> * added the description and the trimmed the test for the problem >>>> >>>> Part of tarantool/tarantool#10199 >>>> --- >>>> src/jit/bcsave.lua | 155 ++------- >>>> ...-865-cross-generation-mach-o-file.test.lua | 294 +++--------------- >>>> 2 files changed, 70 insertions(+), 379 deletions(-) >>>> >>>> diff --git a/src/jit/bcsave.lua b/src/jit/bcsave.lua >>>> index 26ec29c6..61953c2d 100644 >>>> --- a/src/jit/bcsave.lua >>>> +++ b/src/jit/bcsave.lua > > >>>> + subtest:is(mach_o.header.ncmds, 2, >>> Why there are 2 commands for Mach-O format? >>> Please use the named constant. >> is constant name 'ncmds' self-explained? > No, since I don't understand why it is 2 and not 12. Please, add a > comment to make it obvious for any reader. Why it should be 12? I just used a constant from bcsave.lua [1]. I don't get an initial idea behind this number. As I got it right from Mach-O spec `ncmd` is a number of load commands following the header. The possible load commands listed in a table [2], but no one load command listed in a table is used in bcsave.lua for generation Mach-O object file. 1. https://github.com/LuaJIT/LuaJIT/blob/04dca7911ea255f37be799c18d74c305b921c1a6/src/jit/bcsave.lua#L489 2. https://github.com/aidansteele/osx-abi-macho-file-format-reference?tab=readme-ov-file#table-4-mach-o-load-commands >>>> + 'ncmds is correct in Mach-O') >>> Looks like this line may be joined with the previous one. >> joined >>>> end > > > I've added some fixes to your branch: > * Fixed the comment from --- to --. > * Fixed some typos. > * Moved constant declarations to the beginning of the file. > * Join some lines since there is no need to add a new line. Added two more fixes: * moved test description to the top of the test. It would be better to place problem description at the beginning and Mach-O format description before constants. * sorted constants alphabetically * and added a comment: --- a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua +++ b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua @@ -64,6 +64,7 @@ test:plan(1)  local CPU_SUBTYPE_ARM64 = 0x0  local CPU_TYPE_ARM64 = '0x100000c' +-- MH_MAGIC_64: mach-o, big-endian, x64.  local MH_MAGIC_64 = '0xfeedfacf'  -- Relocatable object file.  local MH_OBJECT = 0x1 > > =================================================================== > diff --git a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua > index d30198c0..9963bf88 100644 > --- a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua > +++ b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua > @@ -3,6 +3,12 @@ local test = tap.test('lj-865-cross-generation-mach-o-file') > local utils = require('utils') > local ffi = require('ffi') > > +local CPU_TYPE_ARM64 = '0x100000c' > +local CPU_SUBTYPE_ARM64 = 0x0 > +local MH_MAGIC_64 = '0xfeedfacf' > +-- Relocatable object file. > +local MH_OBJECT = 0x1 > + > test:plan(1) > > -- The test creates an object file in Mach-O format with LuaJIT > @@ -66,64 +72,64 @@ local function create_obj_file(name, arch) > return mach_o_path > end > > --- Parses a buffer in the Mach-O format and returns its fields > --- in a table. > +-- Parses a buffer in the Mach-O format and returns its fields in > +-- a table. > -- The test creates an object file in Mach-O format with LuaJIT > -- bytecode and checks the validity of the object file fields. > ---- > ---- The original problem is reproduced with LuaJIT, which is built > ---- with enabled AVX512F instructions. The support for AVX512F > ---- could be checked in `/proc/cpuinfo` on Linux and > ---- `sysctl hw.optional.avx512f` on Mac. AVX512F must be > ---- implicitly enabled in a C compiler by passing a CPU codename. > ---- Please take a look at the GCC Online Documentation [1] for > ---- available CPU codenames. Also, see the Wikipedia for CPUs with > ---- AVX-512 support [2]. > ---- Execute command below to detect the CPU codename: > ---- `gcc -march=native -Q --help=target | grep march`. > ---- > ---- 1.https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html > ---- 2.https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512 > ---- > ---- Manual steps for reproducing are the following: > ---- > ---- $ CC=gcc TARGET_CFLAGS='skylake-avx512' cmake -S . -B build > ---- $ cmake --build build --parallel > ---- $ echo > test.lua > ---- $ LUA_PATH="src/?.lua;;" luajit -b -o osx -a arm test.lua test.o > ---- $ file test.o > ---- empty.o: DOS executable (block device driver) > - > ---- The format of the Mach-O is described in the document > ---- "OS X ABI Mach-O File Format Reference", published by Apple > ---- company. The copy of the (now removed) official documentation > ---- can be found here [1]. There is a good visual representation > ---- of Mach-O format in "Mac OS X Internals" book (pages 67-68) > ---- [2] and in the [3]. > -- > ---- 0x0000000 --------------------------------------- > ---- | 0xfeedface MH_MAGIC magic > ---- | ------------------------------------ > ---- | 0x00000012 CPU_TYPE_POWERPC cputype > ---- | ------------------------------------ > ---- struct | 0x00000000 CPU_SUBTYPE_POWERPC_ALL cpusubtype > ---- mach_header | ------------------------------------ > ---- | 0x00000002 MH_EXECUTE filetype > ---- | ------------------------------------ > ---- | 0x0000000b 10 load commands ncmds > ---- | ------------------------------------ > ---- | 0x00000574 1396 bytes sizeofcmds > ---- | ------------------------------------ > ---- | 0x00000085 DYLDLINK TWOLEVEL flags > ---- -------------------------------------- > ---- Load commands > ---- --------------------------------------- > ---- Data > ---- --------------------------------------- > ---- > ---- 1.https://github.com/aidansteele/osx-abi-macho-file-format-reference > ---- 2.https://reverseengineering.stackexchange.com/a/6357/46029 > ---- 3.http://formats.kaitai.io/mach_o/index.html > +-- The original problem is reproduced with LuaJIT, which is built > +-- with enabled AVX512F instructions. The support for AVX512F > +-- could be checked in `/proc/cpuinfo` on Linux and > +-- `sysctl hw.optional.avx512f` on Mac. AVX512F must be implicitly > +-- enabled in a C compiler by passing a CPU codename. > +-- Please take a look at the GCC Online Documentation [1] for > +-- available CPU codenames. Also, see the Wikipedia for CPUs with > +-- AVX-512 support [2]. > +-- Execute the command below to detect the CPU codename: > +-- `gcc -march=native -Q --help=target | grep march`. > +-- > +-- 1.https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html > +-- 2.https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512 > +-- > +-- Manual steps for reproducing are the following: > +-- > +-- $ CC=gcc TARGET_CFLAGS='skylake-avx512' cmake -S . -B build > +-- $ cmake --build build --parallel > +-- $ echo > test.lua > +-- $ ./luajit -b -o osx -a arm64 test.lua test.o > +-- $ file test.o > +-- test.o: Mach-O 64-bit arm64 object > + > +-- The format of the Mach-O is described in the document > +-- "OS X ABI Mach-O File Format Reference", published by Apple > +-- company. The copy of the (now removed) official documentation > +-- can be found here [1]. There is a good visual representation > +-- of Mach-O format in "Mac OS X Internals" book (pages 67-68) > +-- [2] and in the [3]. > +-- > +-- 0x0000000 --------------------------------------- > +-- | 0xfeedface MH_MAGIC magic > +-- | ------------------------------------ > +-- | 0x00000012 CPU_TYPE_POWERPC cputype > +-- | ------------------------------------ > +-- struct | 0x00000000 CPU_SUBTYPE_POWERPC_ALL cpusubtype > +-- mach_header | ------------------------------------ > +-- | 0x00000002 MH_EXECUTE filetype > +-- | ------------------------------------ > +-- | 0x0000000b 10 load commands ncmds > +-- | ------------------------------------ > +-- | 0x00000574 1396 bytes sizeofcmds > +-- | ------------------------------------ > +-- | 0x00000085 DYLDLINK TWOLEVEL flags > +-- -------------------------------------- > +-- Load commands > +-- --------------------------------------- > +-- Data > +-- --------------------------------------- > +-- > +-- 1.https://github.com/aidansteele/osx-abi-macho-file-format-reference > +-- 2.https://reverseengineering.stackexchange.com/a/6357/46029 > +-- 3.http://formats.kaitai.io/mach_o/index.html > local function read_mach_o_hdr(buf, hw_arch) > -- LuaJIT always generate 64-bit non-FAT Mach-O object files. > assert(hw_arch == 'arm64') > @@ -138,11 +144,11 @@ local function read_mach_o_hdr(buf, hw_arch) > return mach_header > end > > --- The function builds Mach-O object file and retrieves > --- its header fields. > +-- The function builds a Mach-O object file and retrieves its > +-- header fields. > local function build_and_check_mach_o(subtest) > local hw_arch = subtest.name > - -- LuaJIT always generate 64-bit non-FAT Mach-O object files. > + -- LuaJIT always generates 64-bit, non-FAT Mach-O object files. > assert(hw_arch == 'arm64') > > subtest:plan(5) > @@ -159,19 +165,12 @@ local function build_and_check_mach_o(subtest) > assert(os.remove(mach_o_obj_path), 'remove an object file') > > local magic_str = string.format('%#x', mach_o.magic) > - local MH_MAGIC_64 = '0xfeedfacf' > - subtest:is(magic_str, MH_MAGIC_64, > - 'magic is correct in Mach-O') > + subtest:is(magic_str, MH_MAGIC_64, 'magic is correct in Mach-O') > local cputype_str = string.format('%#x', mach_o.cputype) > - local CPU_TYPE_ARM64 = '0x100000c' > - subtest:is(cputype_str, CPU_TYPE_ARM64, > - 'cputype is correct in Mach-O') > - local CPU_SUBTYPE_ARM64 = 0 > + subtest:is(cputype_str, CPU_TYPE_ARM64, 'cputype is correct in Mach-O') > subtest:is(mach_o.cpusubtype, CPU_SUBTYPE_ARM64, > 'cpusubtype is correct in Mach-O') > - local MH_OBJECT = 1 > - subtest:is(mach_o.filetype, MH_OBJECT, > - 'filetype is correct in Mach-O') > + subtest:is(mach_o.filetype, MH_OBJECT, 'filetype is correct in Mach-O') > subtest:is(mach_o.ncmds, 2, 'ncmds is correct in Mach-O') > end > > =================================================================== > > Please let me know if you have any concerns. > --------------3oAgWQk8WsGXJJy8a0KmKOye Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi, Sergey

thanks for the comments and fixes!

But please don't squash fixes next time.


Sergey

On 11.07.2024 10:29, Sergey Kaplun wrote:
Hi, Sergey!
Thanks for the fixes!
I've applied some minor fixes to your branch.
LGTM, after adding the comment about ncmds value.

On 10.07.24, Sergey Bronnikov wrote:

Sergey,

thanks for review. Fixes applied and force-pushed to the same branch.


Sergey

On 09.07.2024 16:03, Sergey Kaplun via Tarantool-patches wrote:

Hi, Sergey!
Thanks for the patch!
Please consider my comments below.

May we add the test [1] to verify that there will be no regression in the
future?

This "test" was for a FAT binary generated by LuaJIT.

With backported patches, FAT (aka Universal Binary) support is gone.

mach-O header is checked by tests in proposed patch.

OK, let's leave it as is.
Thanks!



        

          
On 05.07.24, Sergey Bronnikov wrote:


          

            
Reported by Sergey Bronnikov.

(cherry picked from commit 7110b935672489afd6ba3eef3e5139d2f3bd05b6)

Previously, LuaJIT generated Mach-O FAT object files for ARM and
ARM64 on macOS. The patch removes support of 32-bit ARM and
FAT object files and now LuaJIT generate Mach-O object files for
ARM64.


          

          
I suppose we should mention that no x86/x86_64 objects are generated
now.


        

        
x86_64 is still there:

$ ./build/gc64/src/luajit -b -o osx -a arm64 empty.lua empty.o
$ file empty.o
empty.o: Mach-O 64-bit arm64 object
$ ./build/gc64/src/luajit -b -o osx -a x64 empty.lua empty.o
$ file empty.o
empty.o: Mach-O 64-bit x86_64 object
$


      

      
My bad, thanks for the clarification.



      

        
Anyway, commit message has been updated.



        

          

            
Sergey Bronnikov:
* added the description and the trimmed the test for the problem

Part of tarantool/tarantool#10199
---
  src/jit/bcsave.lua                            | 155 ++-------
  ...-865-cross-generation-mach-o-file.test.lua | 294 +++---------------
  2 files changed, 70 insertions(+), 379 deletions(-)

diff --git a/src/jit/bcsave.lua b/src/jit/bcsave.lua
index 26ec29c6..61953c2d 100644
--- a/src/jit/bcsave.lua
+++ b/src/jit/bcsave.lua


          

        

      

      
<snipped>



      

        

          

          

            
+  subtest:is(mach_o.header.ncmds, 2,


          

          
Why there are 2 commands for Mach-O format?
Please use the named constant.


        

        
is constant name 'ncmds' self-explained?


      

      
No, since I don't understand why it is 2 and not 12. Please, add a
comment to make it obvious for any reader.


    

    
Why it should be 12?

    
I just used a constant from bcsave.lua [1].

    
I don't get an initial idea behind this number. As I got it right
      from Mach-O spec `ncmd` is a number of load commands following the
      header. The possible load commands listed in a table [2], but no
      one load command

    
listed in a table is used in bcsave.lua for generation Mach-O
      object file.

    


    

    
1.
https://github.com/LuaJIT/LuaJIT/blob/04dca7911ea255f37be799c18d74c305b921c1a6/src/jit/bcsave.lua#L489

    
2.
https://github.com/aidansteele/osx-abi-macho-file-format-reference?tab=readme-ov-file#table-4-mach-o-load-commands

    

    

      

      

        

          

          

            
+             'ncmds is correct in Mach-O')


          

          
Looks like this line may be joined with the previous one.


        

        
joined


        

          

          

            
  end


          

        

      

      
<snipped>

I've added some fixes to your branch:
* Fixed the comment from --- to --.
* Fixed some typos.
* Moved constant declarations to the beginning of the file.
* Join some lines since there is no need to add a new line.

    

    
Added two more fixes:

    
* moved test description to the top of the test. It would be
      better to place problem description

    
at the beginning and Mach-O format description before constants.

    
* sorted constants alphabetically

    
* and added a comment:

    
---
      a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua

      +++
      b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua

      @@ -64,6 +64,7 @@ test:plan(1)

       

       local CPU_SUBTYPE_ARM64 = 0x0

       local CPU_TYPE_ARM64 = '0x100000c'

      +-- MH_MAGIC_64: mach-o, big-endian, x64.

       local MH_MAGIC_64 = '0xfeedfacf'

       -- Relocatable object file.

       local MH_OBJECT = 0x1

    

    


    

    

      

===================================================================
diff --git a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
index d30198c0..9963bf88 100644
--- a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
+++ b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
@@ -3,6 +3,12 @@ local test = tap.test('lj-865-cross-generation-mach-o-file')
 local utils = require('utils')
 local ffi = require('ffi')
 
+local CPU_TYPE_ARM64 = '0x100000c'
+local CPU_SUBTYPE_ARM64 = 0x0
+local MH_MAGIC_64 = '0xfeedfacf'
+-- Relocatable object file.
+local MH_OBJECT = 0x1
+
 test:plan(1)
 
 -- The test creates an object file in Mach-O format with LuaJIT
@@ -66,64 +72,64 @@ local function create_obj_file(name, arch)
   return mach_o_path
 end
 
--- Parses a buffer in the Mach-O format and returns its fields
--- in a table.
+-- Parses a buffer in the Mach-O format and returns its fields in
+-- a table.
 -- The test creates an object file in Mach-O format with LuaJIT
 -- bytecode and checks the validity of the object file fields.
----
---- The original problem is reproduced with LuaJIT, which is built
---- with enabled AVX512F instructions. The support for AVX512F
---- could be checked in `/proc/cpuinfo` on Linux and
---- `sysctl hw.optional.avx512f` on Mac. AVX512F must be
---- implicitly enabled in a C compiler by passing a CPU codename.
---- Please take a look at the GCC Online Documentation [1] for
---- available CPU codenames. Also, see the Wikipedia for CPUs with
---- AVX-512 support [2].
---- Execute command below to detect the CPU codename:
---- `gcc -march=native -Q --help=target | grep march`.
----
---- 1. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
---- 2. https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
----
---- Manual steps for reproducing are the following:
----
---- $ CC=gcc TARGET_CFLAGS='skylake-avx512' cmake -S . -B build
---- $ cmake --build build --parallel
---- $ echo > test.lua
---- $ LUA_PATH="src/?.lua;;" luajit -b -o osx -a arm test.lua test.o
---- $ file test.o
---- empty.o: DOS executable (block device driver)
-
---- The format of the Mach-O is described in the document
---- "OS X ABI Mach-O File Format Reference", published by Apple
---- company. The copy of the (now removed) official documentation
---- can be found here [1]. There is a good visual representation
---- of Mach-O format in "Mac OS X Internals" book (pages 67-68)
---- [2] and in the [3].
 --
---- 0x0000000  ---------------------------------------
----             | 0xfeedface  MH_MAGIC                  magic
----             | ------------------------------------
----             | 0x00000012  CPU_TYPE_POWERPC          cputype
----             | ------------------------------------
---- struct      | 0x00000000  CPU_SUBTYPE_POWERPC_ALL   cpusubtype
---- mach_header | ------------------------------------
----             | 0x00000002  MH_EXECUTE                filetype
----             | ------------------------------------
----             | 0x0000000b  10 load commands          ncmds
----             | ------------------------------------
----             | 0x00000574  1396 bytes                sizeofcmds
----             | ------------------------------------
----             | 0x00000085  DYLDLINK TWOLEVEL         flags
----             --------------------------------------
----               Load commands
----             ---------------------------------------
----               Data
----             ---------------------------------------
----
---- 1. https://github.com/aidansteele/osx-abi-macho-file-format-reference
---- 2. https://reverseengineering.stackexchange.com/a/6357/46029
---- 3. http://formats.kaitai.io/mach_o/index.html
+-- The original problem is reproduced with LuaJIT, which is built
+-- with enabled AVX512F instructions. The support for AVX512F
+-- could be checked in `/proc/cpuinfo` on Linux and
+-- `sysctl hw.optional.avx512f` on Mac. AVX512F must be implicitly
+-- enabled in a C compiler by passing a CPU codename.
+-- Please take a look at the GCC Online Documentation [1] for
+-- available CPU codenames. Also, see the Wikipedia for CPUs with
+-- AVX-512 support [2].
+-- Execute the command below to detect the CPU codename:
+-- `gcc -march=native -Q --help=target | grep march`.
+--
+-- 1. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
+-- 2. https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
+--
+-- Manual steps for reproducing are the following:
+--
+-- $ CC=gcc TARGET_CFLAGS='skylake-avx512' cmake -S . -B build
+-- $ cmake --build build --parallel
+-- $ echo > test.lua
+-- $ ./luajit -b -o osx -a arm64 test.lua test.o
+-- $ file test.o
+-- test.o: Mach-O 64-bit arm64 object
+
+-- The format of the Mach-O is described in the document
+-- "OS X ABI Mach-O File Format Reference", published by Apple
+-- company. The copy of the (now removed) official documentation
+-- can be found here [1]. There is a good visual representation
+-- of Mach-O format in "Mac OS X Internals" book (pages 67-68)
+-- [2] and in the [3].
+--
+-- 0x0000000  ---------------------------------------
+--             | 0xfeedface  MH_MAGIC                  magic
+--             | ------------------------------------
+--             | 0x00000012  CPU_TYPE_POWERPC          cputype
+--             | ------------------------------------
+-- struct      | 0x00000000  CPU_SUBTYPE_POWERPC_ALL   cpusubtype
+-- mach_header | ------------------------------------
+--             | 0x00000002  MH_EXECUTE                filetype
+--             | ------------------------------------
+--             | 0x0000000b  10 load commands          ncmds
+--             | ------------------------------------
+--             | 0x00000574  1396 bytes                sizeofcmds
+--             | ------------------------------------
+--             | 0x00000085  DYLDLINK TWOLEVEL         flags
+--             --------------------------------------
+--               Load commands
+--             ---------------------------------------
+--               Data
+--             ---------------------------------------
+--
+-- 1. https://github.com/aidansteele/osx-abi-macho-file-format-reference
+-- 2. https://reverseengineering.stackexchange.com/a/6357/46029
+-- 3. http://formats.kaitai.io/mach_o/index.html
 local function read_mach_o_hdr(buf, hw_arch)
   -- LuaJIT always generate 64-bit non-FAT Mach-O object files.
   assert(hw_arch == 'arm64')
@@ -138,11 +144,11 @@ local function read_mach_o_hdr(buf, hw_arch)
   return mach_header
 end
 
--- The function builds Mach-O object file and retrieves
--- its header fields.
+-- The function builds a Mach-O object file and retrieves its
+-- header fields.
 local function build_and_check_mach_o(subtest)
   local hw_arch = subtest.name
-  -- LuaJIT always generate 64-bit non-FAT Mach-O object files.
+  -- LuaJIT always generates 64-bit, non-FAT Mach-O object files.
   assert(hw_arch == 'arm64')
 
   subtest:plan(5)
@@ -159,19 +165,12 @@ local function build_and_check_mach_o(subtest)
   assert(os.remove(mach_o_obj_path), 'remove an object file')
 
   local magic_str = string.format('%#x', mach_o.magic)
-  local MH_MAGIC_64 = '0xfeedfacf'
-  subtest:is(magic_str, MH_MAGIC_64,
-             'magic is correct in Mach-O')
+  subtest:is(magic_str, MH_MAGIC_64, 'magic is correct in Mach-O')
   local cputype_str = string.format('%#x', mach_o.cputype)
-  local CPU_TYPE_ARM64 = '0x100000c'
-  subtest:is(cputype_str, CPU_TYPE_ARM64,
-             'cputype is correct in Mach-O')
-  local CPU_SUBTYPE_ARM64 = 0
+  subtest:is(cputype_str, CPU_TYPE_ARM64, 'cputype is correct in Mach-O')
   subtest:is(mach_o.cpusubtype, CPU_SUBTYPE_ARM64,
              'cpusubtype is correct in Mach-O')
-  local MH_OBJECT = 1
-  subtest:is(mach_o.filetype, MH_OBJECT,
-             'filetype is correct in Mach-O')
+  subtest:is(mach_o.filetype, MH_OBJECT, 'filetype is correct in Mach-O')
   subtest:is(mach_o.ncmds, 2, 'ncmds is correct in Mach-O')
 end
 
===================================================================

Please let me know if you have any concerns.



    

  
  


--------------3oAgWQk8WsGXJJy8a0KmKOye--