Fwd: 'Illegal Instruction' on L4Linux
ba_f at rbg.informatik.tu-darmstadt.de
Wed Feb 3 09:54:59 CET 2016
indeed VFP wasn't enabled in CONFIG.
I thought ARMv6 doesn't support VFP, and my L4Linux is built for ARMv6.
Am 2016-02-01 20:29, schrieb 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:
>> 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
>> But, on l4re-snapshot-2014022818 or l4re-snapshot-2014092821 the same
>> 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
> 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
>> (My project is stable on the old snapshots, that's why i try to avoid
>> migrating to current snapshot.)
>> l4-hackers mailing list
>> l4-hackers at os.inf.tu-dresden.de
> Regards, Alexander
More information about the l4-hackers