https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15745
Bug ID: 15745
Summary: Add support for LuaJIt (Lua 5.1 with some Lua 5.2
compatibility)
Product: Wireshark
Version: Git
Hardware: All
OS: All
Status: CONFIRMED
Severity: Enhancement
Priority: Low
Component: Dissection engine (libwireshark)
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Build Information:
Current master: v3.1.0rc0-661-gf0a34311a0 (built with Lua 5.2.4)
--
LuaJIT can potentially speed up Lua dissectors. One disadvantage is that it is
based on Lua 5.1 and has no plans for Lua 5.3 compatibility. On the other hand,
many Lua 5.2 features are supported: https://luajit.org/extensions.html#lua52
Notably, table.unpack is not enabled by default since this requires defining
LUAJIT_ENABLE_LUA52COMPAT. This affects the luajit 2.0.5 build that is
currently installed via Homebrew. This is not a big deal, we can set this
ourselves while loading stdlib.
Lua 5.3 is not supported due to Bug 10881. Notable features in Lua 5.3 were
support for 64-bit integers and bitwise operators. In Lua 5.2 and before,
numbers were always of type 'double'. In Lua 5.3, this is a 64-bit integer by
default or a double depending on the context:
https://www.lua.org/manual/5.3/manual.html#3.4.3
LuaJIT has limited support for 64-bit integers. These are "64 bit int cdata" as
opposed to "number". The syntax is incompatible with Lua, e.g. "123LL" (signed)
or "123ULL" (unsigned), see https://luajit.org/ext_ffi_api.html#literals
Other limitations include:
- Cannot be used as key table key.
https://luajit.org/ext_ffi_semantics.html#cdata_key
- Cannot be used for APIs that expect a number, e.g. "bit.bnot(0ULL)" fails.
Bitwise operations for 32-bit numbers are supported through the bit library
(currently bundled with Wireshark as well, available by default with LuaJIT).
Lua 5.3 also has support for 64-bit bitwise operators (e.g. "1<<63"). LuaJIT
does not support either this syntax or 64-bit bitwise operations natively. For
progress on this, see:
https://github.com/LuaJIT/LuaJIT/issues/63#issuecomment-290395565
Given that Lua 5.3 advantages are small, I think it is better to drop the idea
of using Lua 5.3 and prepare for LuaJIT instead. One early controversy with Lua
was copying the whole source tree into the Wireshark source tree, arguably
because Lua was designed for embedding. This is not the recommended approach
for LuaJIT: https://luajit.org/install.html#embed
While searching for "luajit" and "wireshark", I only found one earlier result:
https://prontog.wordpress.com/2018/12/28/boost-your-lua-wireshark-dissector/
"Using it increased the performance of my dissectors by 1.7x."
I suspect that the overhead of calling TvbRange:__call is dominating, but I
have no profiling data to back this up yet. Improving performance would be
another independent task.
Note: LuaJIT has even more access to functionality from C, so you should not
run untrusted code with it and be careful not to use FFI in a way that can
crash Wireshark. See https://luajit.org/ext_ffi_semantics.html#policy
Tasks:
1. Gather large captures and sample dissectors.
2. Add initial support for building with LuaJIT.
3. Investigate use of FFI or disable it. Calling Wireshark API functions
directly from Lua is likely a very bad idea, it reduces the stability and
compatibility of the Lua dissector to a C plugin. Additionally, the current
WSLUA API is not designed for this kind of thing. Lua errors/exceptions/panics
that cross the C boundary might not be a success story either.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:[email protected]?subject=unsubscribe
