From 3165127f1ae358921e9a50f073de5d80787a384c Mon Sep 17 00:00:00 2001 From: Hugo Musso Gualandi Date: Sat, 24 Jul 2021 15:29:56 -0300 Subject: [PATCH] Reimplement linker hack I think this version of the linker hack has a better change of working on more compilers. If the symbols from lapi.o are being exported, then including Pallene symbols there should probably do the trick! As a bonus, we can get away with not modifying the makefile. --- vm/PALLENE-UPDATING | 22 +--------------------- vm/src/Makefile | 7 ++----- vm/src/lapi.c | 14 ++++++++++++++ vm/src/lua.c | 13 ------------- vm/src/pallene_core.h | 8 +++++++- 5 files changed, 24 insertions(+), 40 deletions(-) diff --git a/vm/PALLENE-UPDATING b/vm/PALLENE-UPDATING index bfcb3569..5b657ccb 100644 --- a/vm/PALLENE-UPDATING +++ b/vm/PALLENE-UPDATING @@ -14,29 +14,9 @@ For the next release, we should consider preparing a proper patch file. 2) Add the Linker Hack to the lua.c - /* - ** PALLENE LINKER HACK - ** - ** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker - ** only includes symbols from the object files where at least one of the symbols of the module is - ** used by the executable itself. This is a problem for the Pallene runtime library, because those - ** symbols are only used by extension modules, which we expect to dynamically link. One hacky - ** workaround I found is to force the "lua" executable to reference one of the symbols from the - ** pallene_code, as done below. - */ - char *pallene_tag_name(int); - char *(*PALLENE_LINKER_HACK)(int) = pallene_tag_name; + See the end of the "lapi.c" 3) Copy the pallene_core files vm/src/pallene_core.h vm/src/pallene_core.c - -4) Update the src/Makefile - - - Add pallene_core.o to the CORE_O list - - Add the pallene_core.o target - - pallene_core.o: pallene_core.c pallene_core.h lapi.h ldo.h lfunc.h \ - lobject.h lstate.h lstring.h ltable.h lvm.h lmem.h lobject.h lstate.h \ - lstring.h ltm.h ltable.h diff --git a/vm/src/Makefile b/vm/src/Makefile index d314278a..f78c0b83 100644 --- a/vm/src/Makefile +++ b/vm/src/Makefile @@ -26,14 +26,14 @@ MYLIBS= MYOBJS= # Special flags for compiler modules; -Os reduces code size. -CMCFLAGS= +CMCFLAGS= # == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE ======= PLATS= guess aix bsd c89 freebsd generic linux linux-readline macosx mingw posix solaris LUA_A= liblua.a -CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o pallene_core.o +CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS) @@ -218,8 +218,5 @@ lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \ ltable.h lvm.h ljumptab.h lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \ lobject.h ltm.h lzio.h -pallene_core.o: pallene_core.c pallene_core.h lapi.h ldo.h lfunc.h \ - lobject.h lstate.h lstring.h ltable.h lvm.h lmem.h lobject.h lstate.h \ - lstring.h ltm.h ltable.h # (end of Makefile) diff --git a/vm/src/lapi.c b/vm/src/lapi.c index f8f70cd0..9087f20d 100644 --- a/vm/src/lapi.c +++ b/vm/src/lapi.c @@ -1453,3 +1453,17 @@ LUA_API void lua_upvaluejoin (lua_State *L, int fidx1, int n1, } +/* +** PALLENE LINKER HACK +** +** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker +** only includes symbols from the object files where at least one of the symbols of the module is +** used by the executable itself. This is a problem for the Pallene runtime library, because those +** symbols are only going to be used by the extension modules, which we expect to dynamically link. +** The hacky workaround that we found is to compile the pallene_core stuff as part of the lapi.o, +** isntead of its own object file. +** +** As a bonus, we also avoid having to modify the Makefile. Conveniently, the set of header files +** that lapi.c depends on is a superset of the header files that pallene_core.c needs. +*/ +#include "pallene_core.c" diff --git a/vm/src/lua.c b/vm/src/lua.c index 736628d1..46b48dba 100644 --- a/vm/src/lua.c +++ b/vm/src/lua.c @@ -657,16 +657,3 @@ int main (int argc, char **argv) { return (result && status == LUA_OK) ? EXIT_SUCCESS : EXIT_FAILURE; } -/* -** PALLENE LINKER HACK -** -** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker -** only includes symbols from the object files where at least one of the symbols of the module is -** used by the executable itself. This is a problem for the Pallene runtime library, because those -** symbols are only used by extension modules, which we expect to dynamically link. One hacky -** workaround I found is to force the "lua" executable to reference one of the symbols from the -** pallene_core, as done below. -*/ -char *pallene_tag_name(int); -char *(*PALLENE_LINKER_HACK)(int) = pallene_tag_name; - diff --git a/vm/src/pallene_core.h b/vm/src/pallene_core.h index 0a92b762..75b28fde 100644 --- a/vm/src/pallene_core.h +++ b/vm/src/pallene_core.h @@ -6,23 +6,29 @@ #ifndef PALLENE_CORE_H #define PALLENE_CORE_H +// This list on includes should include basically everything we need. +// It is copied from lapi.c (grep for PALLENE LINKER HACK for more details) + #include "lua.h" #include "lauxlib.h" #include "lualib.h" #include "lapi.h" +#include "ldebug.h" #include "ldo.h" #include "lfunc.h" #include "lgc.h" +#include "lmem.h" #include "lobject.h" #include "lstate.h" #include "lstring.h" #include "ltable.h" +#include "ltm.h" +#include "lundump.h" #include "lvm.h" #include - #define PALLENE_NORETURN __attribute__((noreturn)) #define PALLENE_UNREACHABLE __builtin_unreachable()