Building luajit2 on Raspbian Stretch: Error: DASM error 11001109 #37
Comments
|
If it helps, I can/have built http://luajit.org/download/LuaJIT-2.0.5.tar.gz entirely successfully on the same machine. |
|
@alecmuffett Hmm, this is strange. Will you try the v2.1 branch of the following github repo on your side please? https://github.com/LuaJIT/LuaJIT/tree/v2.1 Please use the v2.1 branch instead of the default "master" branch. |
|
As requested. It appears to function; log below. |
|
I also got this problem if I using luajit2.1 from https://github.com/LuaJIT/LuaJIT/tree/v2.1 everything is ok |
|
@xsw9527 Are you also on Raspbian Stretch? |
|
@alecmuffett Thanks for your update. @alecmuffett @xsw9527 What version of Raspberry Pi device are you using, respectively? |
|
Raspbian Stretch, latest patches for everything, on a RPi3B with plenty of resources/filesystem/swap. I am not certain that @xsw9527 is using a RPi; his prompt has a system hostname of |
|
@alecmuffett It'll be great if you can help pin down the guilty commit SHA1 in our repo by bisecting the commits. Maybe writing a script to automate the bisecting process. |
|
@alecmuffett In the meantime, I'll try finding a RPi device so that I can actually reproduce and debug this. |
|
@agentzh No promises, but I will have a try tonight. I am familiar with the concept, but am a Git noob (previous: svn, mercurial) so I don't suppose you can recommend a webpage which walks through the Git workflow for bisecting? |
|
@alecmuffett The |
|
@alecmuffett |
|
I am using arm based Linux,I use cross-compile tools to compile luajit in a virtual machine which running Ubuntu 14.04. |
|
I can give you my cross-compile tools if you need,so that you can reproduce this issue easier. |
|
I looked into the code |
|
Bisected: |
|
Hypothesis: this rings a bell from another issue that I logged in Nginx: openresty/lua-nginx-module#1423 ...maybe there's a similar (but incorrect) blind assumption of 64-bit ARM behaviour in the C API code? |
|
For convenience/confirmation, this was the last bad bisect error: |
|
@alecmuffett Thanks for digging it up! I can now reproduce the error on my side with arm cross-compiling. We'll investigate it. |
|
This works fine on FreeBSD 12.0 RBPI3B+ . Must be something Linux related.
|
|
Guys, will you try the following patch on your side? It seems to work fine on my side with cross-compilation (at least it builds successfully): diff --git a/src/lj_obj.h b/src/lj_obj.h
index 08612d7912..94ac9beee9 100644
--- a/src/lj_obj.h
+++ b/src/lj_obj.h
@@ -662,7 +662,11 @@ struct lua_State {
void *cframe; /* End of C stack frame chain. */
MSize stacksize; /* True stack size (incl. LJ_STACK_EXTRA). */
void *exdata; /* user extra data pointer. added by OpenResty */
-};
+}
+#if LJ_TARGET_ARM
+__attribute__ ((aligned (16)))
+#endif
+;
#define G(L) (mref(L->glref, global_State))
#define registry(L) (&G(L)->registrytv) |
|
@sparvu Maybe it's specific to 32-bit arm instead of arm64... |
|
@alecmuffett Show your |
|
@agentzh : ahh. right. i was thinking we are talking only for 64bit arm baords, like RBPI3B+ |
|
@sparvu - the RPi3b is a 64-bit chip, but Raspbian is a 32-bit OS because 1GB of ram is limited when running in 64-bit mode |
...it compiles to completion; I can't find a test suite? (edit: though there's a curious Perl module) |
|
@sparvu <https://github.com/sparvu> - the RPi3b is a 64-bit chip, but Raspbian is a 32-bit OS because 1GB of ram is limited when running in 64-bit mode
@alecmuffett <https://github.com/alecmuffett> : greetings from Finland (old Sun PS team)
right. you are on 32bit using Raspbian. We have moved from Linux to
FreeBSD. It boots fine using RBPI3b boards in 64bit
krmx@k50dev:~ % getconf LONG_BIT
64
|
|
@sparvu I thought I recognised the name! :-) |
|
@alecmuffett Good to know it compiles fine on your side with my patch. You can try running the test suite here: https://github.com/openresty/luajit2-test-suite BTW, the memory limit is 128TB (hence actually no limit on most, if not all systems) when building LuaJIT on arm64 because the GC64 mode is enforced on that architecture. |
|
These are headless machines, is there a way to run tests without a GTK dependency? |
|
@alecmuffett Some of the tests just manipulates the gtk 2 libraries. It does not require a desktop environment nor an X window server. I always run the tests in a headless server myself. And that github repo also runs the test suite in Travis CI, which is also a headless environment. |
|
See https://github.com/openresty/luajit2-test-suite/blob/master/.travis.yml for more details. |
|
Just for the record, here are some details for this issue: The original There were many offending DynASM instructions that set this The DynASM instruction encoding statement looks like this (at host/buildvm_arch.h:6601): dasm_put(Dst, 110, Dt2(->vmstate), ~CFRAME_RAWMASK, Dt1(->base), Dt1(->glref), ~LJ_TFALSE, GG_G2DISP, LJ_VMST_INTERP, DISPATCH_GL(vmstate));The offending instruction operand is the value of This #define GG_G2DISP (GG_OFS(dispatch) - GG_OFS(g))where #define GG_OFS(field) ((int)offsetof(GG_State, field))where typedef struct GG_State {
lua_State L; /* Main thread. */
global_State g; /* Global state. */
...Thus, GG_OFS() returns different values based on the size of My previous patch enforces 16-byte alignment in lua_State, which is overkill. The following patch is a bit more efficient in that it saves 4 bytes in every lua_State object (from 64 bytes to 60 bytes) on 32-bit ARM systems: diff --git a/src/lj_obj.h b/src/lj_obj.h
index 08612d7912..a89ea0d982 100644
--- a/src/lj_obj.h
+++ b/src/lj_obj.h
@@ -662,6 +662,10 @@ struct lua_State {
void *cframe; /* End of C stack frame chain. */
MSize stacksize; /* True stack size (incl. LJ_STACK_EXTRA). */
void *exdata; /* user extra data pointer. added by OpenResty */
+#if LJ_TARGET_ARM
+ uint32_t unused1;
+ uint32_t unused2;
+#endif
};
#define G(L) (mref(L->glref, global_State))Because we are now padding the struct size ourselves, it is also more portable (no longer requires the gcc attribute support). I've run the test suite using qemu-arm on my side and most of the tests are passing. Also I checked the failures are also present when running the test suite with the official v2.1 branch. Most of the failures are due to the lack of arm versions of gtk and mpc libraries in my system. The details of the failures are like below: https://gist.github.com/agentzh/1295b2ad913f1bcf32a65733460ab3f1 The only test failure that really deserves further investigation is the one in compare.lua: When print out the expression value, it is indeed negative: But for some reason, |
|
Patch is already committed. |
|
I've already get all the tests pass with cross-compiled arm and aarch64 builds of LuaJIT on my Linux x86_64 system using qemu user mode. The only remaining issue is the failure in compile.lua for the ARM build, as mentioned above. Created issue #38 to record this. |
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduces size_t fields do not violate the alligment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduces size_t fields do not violate the alignment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduced size_t fields do not violate the alignment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduced size_t fields do not violate the alignment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduced size_t fields do not violate the alignment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
This patch introduces the following counters: - overall amount of allocated tables, cdata and udata objects - number of incremental GC steps grouped by GC state - number of string hashes hits and misses - amount of allocated and freed memory - number of trace aborts, number of traces and restored snapshots Also this patch fixes alignment for 64-bit architectures. NB: MSize and BCIns are the only fixed types that equal 32 bits. GCRef, MRef and GCSize sizes depend on LJ_GC64 define. struct GCState is terminated by three fields: GCSize estimate, MSize stepmul and MSize pause, which are aligned. The introduced size_t fields do not violate the alignment too. vmstate 32-bit field goes right after GCState field within global_State structure. The next field tmpbuf consists of several MRef fields that have 64-bit size each. This issue can be solved by moving vmstate field below. However DynASM doesn't work well with unaligned memory access on 64-bit bigendian MIPS, so vmstate should be aligned to a 64-bit boundary. Furthermore field order has been changed to be able to compile code by DynASM for 32-bit ARM too (see also openresty/luajit2#37 (comment)). Interfaces to obtain these metrics via both Lua and C API are introduced in the next patch. Part of tarantool/tarantool#5187
Hi! I am trying to build the latest repo on Raspbian Stretch (fully up to date) and encountering this:
I'm not really sure where to go with this, I've dug into
buildvm.ca bit, and11001109seems to be a complex status code returned by one of two possible functions?The text was updated successfully, but these errors were encountered: