On Tuesday 18. July 2017 16.56.08 Paul Boddie wrote:
So, I applied the Fiasco patch and then looked at the above file, checking the objdump output for the l4re binary. With the patch applied, the page fault did not occur endlessly, and with a change to the above file similar to those already made for sigma0 and moe, it appears that the page fault is eliminated completely. As a consequence, the "hello" example now runs, finally!
Despite this success, I should point out that Ned doesn't manage to function at all. It would appear that upon starting, Ned tries to import various Lua libraries, and the second one causes a page fault:
Ned says: Hi World! L = luaL_newstate() luaL_requiref(L, "_G", libs[0].func, 1) luaL_requiref(L, "package", libs[1].func, 1) createclibstable(L) luaL_newlib(L, pk_funcs) L4Re[rm]: unhandled read page fault at 0x8 pc=0x10350cc
Here, the first and last lines are normal logging output. The other lines are from my clumsy debugging statements. The exception always seems to occur in the luaL_checkversion_ function in...
pkg/l4re-core/lua/lib/contrib/src/lauxlib.c
...coincidentally when performing an operation like this:
sdc1 $f20,48(sp)
Looking at the registers in the kernel debugger, sp refers to a kernel address. Meanwhile, the t9 and gp addresses are valid for accesses to the global offset table (verified from an objdump on ned):
t9=0101b2f8 gp=0109adc0 sp=80c41ef8
Trying to check the stack pointer in the offending function is awkward because gcc will happily move any statement printing it out after instructions causing the page fault. Replacing the code with the stack pointer output statements produces a value of 0x8cd8 for sp, which is not a kernel address at least, but I have no idea if it is (or seems) valid.
A side-effect of removing the version-checking code is that this does not then obstruct the rest of the package-importing operations. However, another exception of this nature arises when attempting to invoke the execute_lua_buf function in...
pkg/l4re-core/ned/server/src/lua.cc
It always seems to involve an address of 0x8, which seems rather bizarre. Again, I think I must be missing something fundamental and must only be seeing the consequences.
Paul