Re: LuaJIT 2.0 beta 9 on PPC GCC 4.4.6 uClibc 0.9.29 mpc8248 PowerQuicc II processor

[Mike Pall <mikelu-1202@...>]

Solinsky, Jeff - PAL wrote:
> The crash is occurring when unmapping linux-vdso32.so.1

Oh, I see ... actually that's not how it should work. The VDSO
segment is always present in the process space, because the kernel
creates it. Including proper ELF headers and such.

The dynamic loader only sets up a virtual name mapping from
'linux-vdso32.so.1' to that segment. It does _NOT_ actually access
or load this file from disk. In fact, no such file is present in
my PPC distro! So it doesn't really need to unload anything, either.

Here's the interesting part of the output of:
  strace luajit -e 'io.stderr:write"X"; for i=1,100 do end'

----
*** This write happens before anything is JIT-compiled
write(2, "X", 1)                        = 1

*** Machine code segment for JIT code is created and written to
mmap2(0x10360000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x10360000

*** Segment is write-protected and made executable
mprotect(0x10360000, 32768, PROT_READ|PROT_EXEC) = 0

*** VDSO call to __kernel_sync_dicache is not shown by strace

*** <-- Generated machine code is executed here

*** Interrupt handler disabled by exit code in luajit.c
rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTART}, {0x10002dc0, [INT], SA_RESTART}, 8) = 0

*** Machine code segment unmapped
munmap(0x10360000, 32768)               = 0

*** Memory allocator segment unmapped
munmap(0x48029000, 131072)              = 0

*** Exit of process
exit_group(0)                           = ?
----

As you can see, there's no load or map/unmap of linux-vdso32.so.1.
This is all handled internally by dlopen().

I guess this is another case of a mismatch between uClibc and the
kernel capabilities. Not sure what to do about it.

> which is a decent indication that maybe I did something wrong in
> __kernel_sync_dicache() when I added the code that also
> invalidates the instruction cache instead of only the data
> cache?

I don't think so. That would cause spurious crashes during
execution, not just a crash at the end.

> V_FUNCTION_BEGIN(__kernel_sync_dicache)

Technically you could add this code to buildvm_ppc.dasc as
->vm_sync_ppc and call it (with a proper declaration in lj_vm.h)
as lj_vm_sync_ppc() from inside lj_mcode_sync(). Use 'r0' instead
of '0' in dcbst and icbi.

I've not done so, because cache flushing is very CPU-specific on
PPC. E.g. the cache line size differs between CPUs. It may even
depend on some setting that's only known by the kernel.

--Mike