[Openmcl-devel] Illegal Instruction in CCL 1.11.5 on Musl Libc

[Will Sinatra]

That's a fair point, I suppose this is an issue with how what the C is
translating to, not necessarily the C itself. I really appreciate you
taking the time to point me in the right direction!

Strace does at least get a mmap call:

execve("./lx86cl64", ["./lx86cl64"], 0x7ffe93476570 /* 19 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7f54b3b13d48) = 0
set_tid_address(0x7f54b3b1431c)         = 29949
mprotect(0x7f54b3b10000, 4096, PROT_READ) = 0
mprotect(0x431000, 4096, PROT_READ)     = 0
arch_prctl(ARCH_SET_FS, 0x7f54b3b14530) = 0
set_tid_address(0x7f54b3b1431c)         = 29949
uname({sysname="Linux", nodename="kw-repo", ...}) = 0
readlink("/proc/self/exe", "/home/wsinatra/WS-Alpine-Package"..., 4096) = 62
arch_prctl(ARCH_GET_GS, [NULL])         = 0
arch_prctl(ARCH_GET_FS, [0x7f54b3b14530]) = 0
mmap(0x15000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x15000
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x40d6f4} ---
+++ killed by SIGILL +++
Illegal instruction

Just a guess, but we're trying to mmap 0x15000, which if looking at
the mappings contains nothing? That's probably just because the call
fails and GDB is dumping the information after the program fails
though..

(gdb) info proc mappings
process 29995
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
             0x15000            0x16000     0x1000        0x0
            0x400000           0x430000    0x30000        0x0
/home/wsinatra/WS-Alpine-Packages/testing/ccl/src/ccl/lx86cl64
            0x431000           0x432000     0x1000    0x30000
/home/wsinatra/WS-Alpine-Packages/testing/ccl/src/ccl/lx86cl64
            0x432000           0x433000     0x1000    0x31000
/home/wsinatra/WS-Alpine-Packages/testing/ccl/src/ccl/lx86cl64
      0x7ffff7f64000     0x7ffff7f67000     0x3000        0x0 [vvar]
      0x7ffff7f67000     0x7ffff7f69000     0x2000        0x0 [vdso]
      0x7ffff7f69000     0x7ffff7ff9000    0x90000        0x0
/lib/ld-musl-x86_64.so.1
      0x7ffff7ffa000     0x7ffff7ffb000     0x1000    0x90000
/lib/ld-musl-x86_64.so.1
      0x7ffff7ffb000     0x7ffff7ffc000     0x1000    0x91000
/lib/ld-musl-x86_64.so.1
      0x7ffff7ffc000     0x7ffff7fff000     0x3000        0x0
      0x7ffffffde000     0x7ffffffff000    0x21000        0x0 [stack]

On Wed, Dec 18, 2019 at 12:59 PM Waldek Hebisch
<hebisch at math.uni.wroc.pl> wrote:
>
> >
> > Looking at the disassembly of remap_spjump I'm seeing:
> >
> > (gdb) disass remap_spjump
> > Dump of assembler code for function remap_spjump:
> > Address range 0x415630 to 0x415676:
> >    0x0000000000415630 <+0>:     sub    $0x8,%rsp
> >    0x0000000000415634 <+4>:     xor    %r9d,%r9d
> >    0x0000000000415637 <+7>:     mov    $0xffffffff,%r8d
> >    0x000000000041563d <+13>:    mov    $0x32,%ecx
> >    0x0000000000415642 <+18>:    mov    $0x3,%edx
> >    0x0000000000415647 <+23>:    mov    $0x1000,%esi
> >    0x000000000041564c <+28>:    mov    $0x15000,%edi
> >    0x0000000000415651 <+33>:    callq  0x40d2e0 <mmap at plt>
> >    0x0000000000415656 <+38>:    cmp    $0xffffffffffffffff,%rax
>                                   ^^^^^^
> >    0x000000000041565a <+42>:    jne    0x40d6f4 <remap_spjump+4294934724>
> >    0x0000000000415660 <+48>:    lea    0x12ae2(%rip),%rdi        # 0x428149
> >    0x0000000000415667 <+55>:    callq  0x40d1c0 <perror at plt>
> >    0x000000000041566c <+60>:    mov    $0x1,%edi
> >    0x0000000000415671 <+65>:    callq  0x40d600 <_exit at plt>
> > Address range 0x40d6f4 to 0x40d6f6:
> > => 0x000000000040d6f4 <+-32572>:        ud2
> > End of assembler dump.
> >
> > I wish I was more familiar with C, most of this I'm only roughly
> > familiar with. I don't see anything that immediately jumps out as
> > problematic,  but maybe someone with a more seasoned eye would.
>
> Looks like failing memory allocation.  After that openmcl tries to
> print error message and exit.  But maybe things are so horribly
> broken that calls go to different functions.  I would suggest
> using 'strace'.  If at end of dump you see call to mmap, then
> you may get some info.  If not, things got messed up earlier.
>
> To debug this you need almost no C knowledge, you need to work
> at assebler level.  Anyway, to go forward you need somebody more
> familiar with Openmcl (I worked on runtimes for other systems,
> but not on Openmcl).
>
> --
>                               Waldek Hebisch
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel