Discussion:
__asm__("redir"): LuaJIT vs. GCC
Tomash Brechko
2014-09-26 11:07:56 UTC
Permalink
Hello!

LuaJIT supports __asm__("redir") construct to rename symbols in
ffi.cdef(). However if I read the code correctly than on POSIX system this
"redir" name is then passed to dlsym(). This deviates from GCC in the
following way: on some systems symbols are internally prefixed with an
underscore (certainly not Linux, likely OSX but can't test that). On (some
of, likely most of) those systems when you do dlsym("redir") it actually
looks up for "_redir" (i.e. you do not have to prefix name passed to
dlsym() with underscore explicitly). So LuaJIT's __asm__("redir") will
look for "_redir" symbol and won't find "redir" name create by GCC's
__asm__("redir"). From GCC docs:

"On systems where an underscore is normally prepended to the name of a C
function or variable, this feature allows you to define names for the
linker that do not start with an underscore."

from OXS dlsym() docs:

"The symbol name passed to dlsym() is the name used in C source code.
For example to find the address of function foo(), you would pass "foo" as
the symbol name. This is unlike the older dyld APIs which required a
leading underscore."

GCC's __asm__("redir") name will be inaccessible for dlsym() on OSX if it
still uses underscore prefix internally (reportedly so).

Actually I find LuaJIT behaviour more fit for creating symbol aliases. So
I'd like to confirm that LuaJIT doesn't somehow magically bypass dlsym()
for its __asm__("redir") implementation, and this behaviour won't change
(likely impossible to change without some heavy lifting, but still), and is
not planned to be removed.

Thanks!
--
Tomash Brechko
Mike Pall
2014-09-26 13:00:48 UTC
Permalink
Post by Tomash Brechko
Actually I find LuaJIT behaviour more fit for creating symbol aliases. So
I'd like to confirm that LuaJIT doesn't somehow magically bypass dlsym()
for its __asm__("redir") implementation, and this behaviour won't change
(likely impossible to change without some heavy lifting, but still), and is
not planned to be removed.
Since there's no easy way to change the behavior (and OSX is a mess
anyway), I'm not going to touch that area of code.

--Mike

Loading...