From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Bronnikov <estetus@gmail.com>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit v2 1/1] Fix saved bytecode encapsulated in ELF objects.
Date: Tue, 6 Jun 2023 15:31:57 +0300 [thread overview]
Message-ID: <ZH8nPQpqTu4vuPhO@root> (raw)
In-Reply-To: <7be88fa24695ad2f3c15a9a23bd884ca0acc36f5.1685433737.git.sergeyb@tarantool.org>
Hi, Sergey!
Thanks for the fixes!
I've reviewed the branch version, since changes was made after Max's
review.
LGTM, with minor nits below.
On 30.05.23, Sergey Bronnikov wrote:
> From: Sergey Bronnikov <sergeyb@tarantool.org>
>
> Thanks to Dimitry Andric.
>
> (cherry picked from commit 7dbf0b05f1228c1c719866db5e5f3d58f87f74c8)
>
> Function `bcsave.lua:bcsave_elfobj()` produced an object file in ELF
> format with a wrong size size of `.strtab`. Wrong .strtab size causes lld to
Looks like this paragraph is too wide for git commit format. You may
replace it with the following* :
| Function `bcsave.lua:bcsave_elfobj()` produced an object file in ELF
| format with a wrong size size of `.strtab`. Wrong .strtab size causes
| lld to show an error message:
*: I got this via the `V}gq` in vim -- it may be used for formatting
according to permitted line width :).
> show an error message:
>
> ```
> $ luajit -b -n "module_name" -e "print()" xxx.obj
> $ ld.lld xxx.obj
> ld.lld: error: xxx.obj: SHT_STRTAB string table section [index 3] is non-null terminated
> ```
Minor: please, comment that the starting \0 byte [1] was forgotten to
count. And the patch fixes the counting.
>
> Sergey Bronnikov:
> * added the description and the test for the problem
>
> Signed-off-by: Sergey Bronnikov <sergeyb@tarantool.org>
> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
> Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org>
> ---
>
> Changes in v2:
> - Fixed comments as per review by Sergey.
>
> Branch: https://github.com/tarantool/luajit/tree/ligurio/gh-366-strtab-section-correct-size
> Tarantool CI: https://github.com/ligurio/tarantool/tree/ligurio/gh-xxxx-strtab-section-correct-size
Side note: CI results are available here:
https://github.com/tarantool/tarantool/pull/8678
>
> src/jit/bcsave.lua | 2 +-
> .../lj-366-strtab-correct-size.test.lua | 202 ++++++++++++++++++
> 2 files changed, 203 insertions(+), 1 deletion(-)
> create mode 100644 test/tarantool-tests/lj-366-strtab-correct-size.test.lua
>
> diff --git a/src/jit/bcsave.lua b/src/jit/bcsave.lua
> index c17c88e0..2553d97e 100644
> --- a/src/jit/bcsave.lua
> +++ b/src/jit/bcsave.lua
<snipped>
> diff --git a/test/tarantool-tests/lj-366-strtab-correct-size.test.lua b/test/tarantool-tests/lj-366-strtab-correct-size.test.lua
> new file mode 100644
> index 00000000..5dec6751
> --- /dev/null
> +++ b/test/tarantool-tests/lj-366-strtab-correct-size.test.lua
> @@ -0,0 +1,202 @@
<snipped>
> +-- with name 'luaJIT_BC_lango_team':
Nit: Comment width is more than 66 symbols, here and below.
(Obviously there is no need to change the output of utilities, but only
comments themselves.)
> +--
> +-- $ readelf --symbols xxx.obj
> +--
> +-- Symbol table '.symtab' contains 2 entries:
> +-- Num: Value Size Type Bind Vis Ndx Name
> +-- 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> +-- 1: 0000000000000000 66 OBJECT GLOBAL DEFAULT 4 luaJIT_BC_lango_team
> +--
> +-- and displaying the information contained in the file's section headers, if
> +-- it has any. For our purposes we are interesting in section .symtab,
> +-- so other sections snipped in the output:
According the latest version on the branch:
===================================================================
+-- and to dsisplay the information contained in the file's section headers, if
Typo: s/dsisplay/display/
+-- it has any. For our purposes we are interesting in .symtab section,
Typo: s/For out purposes/For out purposes,/
Typo: s/we are interesting/we are interested/
+-- so other sections are snipped in the output:
+--
+-- $ readelf --section-headers xxx.obj
+-- There are 6 section headers, starting at offset 0x40:
+--
===================================================================
> +--
> +-- $ readelf --section-headers xxx.obj
> +-- There are 6 section headers, starting at offset 0x40:
> +--
> +-- Section Headers:
> +-- [Nr] Name Type Address Offset
> +-- Size EntSize Flags Link Info Align
> +-- ...
> +--
> +-- [ 3] .strtab STRTAB 0000000000000000 00000223
> +-- 0000000000000016 0000000000000000 0 0 1
> +-- ...
> +-- Reference numbers for strtab offset and size could be obtained with
> +-- readelf(1). Note that number system of these numbers are hexadecimal.
Typo: s/number system ... are/number system ... is/
> +
> +local expected_strtab_size = 0x16
Minor:
I suggest to make it more specific to be clearer to understand what is
that magic number:
| local SYM_NAME_EXPECTED = LJBC_PREFIX .. MODULE_NAME
| -- The first \0 byte, which is index zero + length of the string
| -- + terminating \0 byte = 0x16.
| local EXPECTED_STRTAB_SIZE = 1 + #SYM_NAME_EXPECTED + 1
> +local expected_strtab_offset = 0x223
> +local module_name = 'lango_team'
> +
> +-- Symbol name prefix for LuaJIT bytecode defined in bcsave.lua.
> +local LJBC_PREFIX = 'luaJIT_BC_'
> +
> +-- Defined in elf.h.
> +local SHT_SYMTAB = 2
> +
> +-- Using the same declarations as defined in <src/jit/bcsave.lua>.
> +ffi.cdef[[
<snipped>
> +]]
> +
> +local is64_arch = {
> + ['x64'] = true,
> + ['arm64'] = true,
> + ['arm64be'] = true,
> + ['ppc'] = false,
> + ['mips'] = false,
> +}
| I would left unsupported arch's here as well, it will simplify a bit work
| for those who will port test to these arch's in a future.
Minor: I'm not against this approach at all. I'm a little bit confused
that we use `or false` for initializing `is64` variable below -- I
suppose, it can be skipped, so we'll get `true` for well-known and
supported arches (x64, arm64, arm64be), `false` for supported non-64-bit
arches (ppc, mips) and `nil` for unknown arches.
> +
> +local is64 = is64_arch[jit.arch] or false
I suggest to replace with
| local is64 = is64_arch[jit.arch]
Feel free to ignore.
See comment above.
> +
> +local function create_obj_file(name)
<snipped>
> --
> 2.34.1
>
[1]: https://refspecs.linuxbase.org/elf/gabi4+/ch4.strtab.html
--
Best regards,
Sergey Kaplun
next prev parent reply other threads:[~2023-06-06 12:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 8:09 Sergey Bronnikov via Tarantool-patches
2023-05-30 9:05 ` Maxim Kokryashkin via Tarantool-patches
2023-05-31 14:50 ` Sergey Bronnikov via Tarantool-patches
2023-06-06 12:55 ` Sergey Kaplun via Tarantool-patches
2023-06-06 12:31 ` Sergey Kaplun via Tarantool-patches [this message]
2023-06-06 14:14 ` Sergey Bronnikov via Tarantool-patches
2023-07-04 17:09 ` Igor Munkin via Tarantool-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH8nPQpqTu4vuPhO@root \
--to=tarantool-patches@dev.tarantool.org \
--cc=estetus@gmail.com \
--cc=skaplun@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH luajit v2 1/1] Fix saved bytecode encapsulated in ELF objects.' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox