Fwd: 'Illegal Instruction' on L4Linux

[Alexander Tarasikov]

Forwarding here just in case someone stumbles on this thread. Forgot
to reply-all :(


---------- Forwarded message ----------
From: Alexander Tarasikov <alexander.tarasikov at gmail.com>
Date: Mon, Feb 1, 2016 at 10:28 PM
Subject: Re: 'Illegal Instruction' on L4Linux
To: ba_f <ba_f at rbg.informatik.tu-darmstadt.de>


On Mon, Feb 1, 2016 at 8:53 PM, ba_f
<ba_f at rbg.informatik.tu-darmstadt.de> wrote:
> Hello,
>
>
> i have an issue with apps running on L4Linux.
>
> /usr/bin # ./helloWorld
> Illegal instruction
>
> Actually, on the current l4re-snapshot-2015123115 my apps run without
> problem.
> But, on l4re-snapshot-2014022818 or l4re-snapshot-2014092821 the same app
> don't works.
> All apps say 'Illegal instruction'.
>
> I've built for Zynq.
>
>
> Any idea what's wrong?

You have not provided enough information. For example, how you compile
Fiasco, L4Re and L4Linux.
My experience with L4Re tells me you probably forgot to enable
VFP/NEON in configuration options - check the menuconfig for Fiasco,
L4Re and L4Linux. Most likely what happened is that the newer
toolchain is by default using the "hardfloat" ABI and the compiler
generates VFP/NEON instructions.

If that fails, I suggest that you try debugging it yourself
Therefore, there are several places you should look at:

1) First, you could try running the app under gdb. It will then print
the stack trace and point to the offending instruction.

2) You could also install a SIGILL handler in your app and see what's
the actual instruction causing the fault. I have an example code here
- https://gist.github.com/astarasikov/9369538#file-arm-sigill-example-L71.
It's actually a complicated example that patches the code at runtime.
What you need to look at is at the following lines in "my_sh":
# ucontext_t *uc = (ucontext_t*)data;
# struct sigcontext *ctx = &(((ucontext_t*)uc)->uc_mcontext);
# ctx->arm_pc; //this is the address of the instruction. You can
printf it (as an unsigned integer) and decode the instruction.

3) If that fails, you could patch the invalid opcode handler in kernel
to print the instruction. You should grep "arch/arm" and "arch/l4" for
"SIGILL". Then, you can add the code to the trap handler.
Alternatively, if you build kernel with CONFIG_DEBUG and
CONFIG_DEBUG_USER, you will be able to see the stack trace and the hex
dump of the instruction in the "dmesg" (or on the serial port
console).

>
> (My project is stable on the old snapshots, that's why i try to avoid
> migrating to current snapshot.)
>
>
>
> thanks,
> ba_f
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers



--
Regards, Alexander


-- 
Regards, Alexander