Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [PATCH]: armcap.c, do not execute neon/cortex tests on Linux
36 views
Skip to first unread message
Andy Polyakov
Jul 16, 2012, 8:27:41 AM7/16/12
to
> I've been getting "undefined instruction" errors in my syslog caused by
> the cpu features detection code
> in armcap.c. These messages show up when CONFIG_DEBUG_USER is enabled
> in the kernel.
Kernel source reads that you also have to initialize specific bit in a
variable. I assume through command line to kernel (see /proc/cmdline)?
> To eliminate the errors I have updated the cpu detection code to use
> /proc/self/auxv and /proc/cpuinfo
> when compiled on Linux. Since the indentation style does not match the
> original code, I will redo
> the patch if you decide you want to roll it into your source tree.
Well, it's not directly desired, because it adds dependency on /proc
being mounted. Then I'm not sure that asm/hwcap.h is present in all SDKs
targeting platforms where the code can be compiled. And it's not really
error (as it's totally intentional), log is there for some specific
debugging purposes. Arguably it's as appropriate to disable that
particular message on your system. You can also set OPENSSL_armcap
variable to bypass the probing. In other words it's not really
interesting for main stream. But of course you can do it on your own, in
which case I'd recommend to move the code below
getenv("OPENSSL_armcap"), so that there is a way to override it with
environment variable.
> Correct my if I'm wrong, but I'm pretty sure that ARMV7_TICK should be
> enabled only on cortex processors.
Well, my understanding is that it's part of ARMv7 specification, so that
any ARMv7 processor qualifies. But! Even if processor supports it, it's
not as simple as looking at /proc/cpuinfo. For _armv7_tick to work
*privileged* control registers has to be configured accordingly. I mean
CPU model alone doesn't guarantee that user-land _armv7_tick works.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org
> the cpu features detection code
> in armcap.c. These messages show up when CONFIG_DEBUG_USER is enabled
> in the kernel.
Kernel source reads that you also have to initialize specific bit in a
variable. I assume through command line to kernel (see /proc/cmdline)?
> To eliminate the errors I have updated the cpu detection code to use
> /proc/self/auxv and /proc/cpuinfo
> when compiled on Linux. Since the indentation style does not match the
> original code, I will redo
> the patch if you decide you want to roll it into your source tree.
Well, it's not directly desired, because it adds dependency on /proc
being mounted. Then I'm not sure that asm/hwcap.h is present in all SDKs
targeting platforms where the code can be compiled. And it's not really
error (as it's totally intentional), log is there for some specific
debugging purposes. Arguably it's as appropriate to disable that
particular message on your system. You can also set OPENSSL_armcap
variable to bypass the probing. In other words it's not really
interesting for main stream. But of course you can do it on your own, in
which case I'd recommend to move the code below
getenv("OPENSSL_armcap"), so that there is a way to override it with
environment variable.
> Correct my if I'm wrong, but I'm pretty sure that ARMV7_TICK should be
> enabled only on cortex processors.
Well, my understanding is that it's part of ARMv7 specification, so that
any ARMv7 processor qualifies. But! Even if processor supports it, it's
not as simple as looking at /proc/cpuinfo. For _armv7_tick to work
*privileged* control registers has to be configured accordingly. I mean
CPU model alone doesn't guarantee that user-land _armv7_tick works.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org
0 new messages