On Fri, 27 May 2016 00:25:48 +0200 Nicolas Aguirre <[email protected]> said:
> Hi, > > i'm crosscompiling EFL for raspberrypi, and NEON is detected, but > raspberrypi (v1) has no NEON extension. It's causing an illegal > instruction in evas_common_cpu_neon_test. > > gdb output : > > Program received signal SIGILL, Illegal instruction. > evas_common_cpu_neon_test () at lib/evas/common/evas_cpu.c:103 > 103 asm volatile ( > > I building a recent EFL tree (f891cdc) > > Is --disable-neon my best option or automatic detection can be use? > I'm pretty sure it was working with older release of efl. ummm well out detection is if the compiler can correctly compile some code with the compiler. it needs arm_neon.h and vqadd neon instruction. perhaps before the compiler failed because you were compiling armv6 and thus it refused. maybe it's stopped refusing and now compiles blindly. how are we expected to sanely detect this now when the compiler can and will produce armv6 code and happily drop in neon asm instructions and not fail? so what we do have is a RUNTIME check. those illegal instructions are there because the compiler says it's ok do do this given your compiler and the cflags etc. you have. so at RUNTIME that evas_cpu.c has a small check - it tries to execute a neon instruction (that check would be empty if compiling in neon was not allowed), and if this succeeds without a SIGILL ... then neon will work on that cpu. we have to do this as some armv7's do not have neon units. the older tegra cpu's didn't have neon for example. we TRAP the SIGILL with a signal handler so the exception is ok ... unless of course you are under gdb etc. - then YOU get it anyway ... but you can just "continue" as evas's trap will catch this SIGILL and move on. this has been done on x86 cpu's too for like 10+ years detecting various versions of mmx, mmx2, sse, sse3, sse4 etc. :) we use the same "execute sample instruction and trap it" to figure this out. if you want to force a cpu feature to turn off try: export EVAS_CPU_NO_NEON=x then the test will not even be tried. i will assume no neon always. handy for debugging when you don't want to get the traps in your gdb. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
