On 3/19/18 4:35 PM, Steve Pavao wrote:
Hi Andre,
On Mar 19, 2018, at 5:32 PM, Andre McCurdy <armccu...@gmail.com
<mailto:armccu...@gmail.com>> wrote:
On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <ste...@korgrd.com
<mailto:ste...@korgrd.com>> wrote:
What’s the recommended way to be able to propogate target-specific
compile-time CPU tune information to affect the build of a source
file in my own custom layer?
For example, if I’m building for an arm6-based target, I’d like to be
able to have the __ARM_ARCH_6__ symbol be available when the Yocto
system builds my custom layer. The BSP for such a target obviously
defines this symbol when building its files for such a target. Is
there an easy way to propagate this information to my own custom
layer, to affect my own sources? Maybe my recipe needs to include
certain conf files from other layers such as meta or the BSP layer?
This kind of macro is typically defined internally by gcc, depending
on the -mcpu etc options passed on the gcc command line, ie options
which are included in the ${CC} definition setup by OE.
Therefore all you normally need to do is ensure that the Makefiles etc
for the components in your custom layer all correctly respect OE's
definition of ${CC}.
A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
"$(CROSS_COMPILE)gcc") and lose the original value passed via the
environment.
Currently, I notice that architecture-level symbols are available to
my custom layer at compile time, such as __aarch64_ and __arm__, but
not CPU tune information, such as __ARM_ARCH_6__.
The exact set of macros defined by gcc will vary depending on exactly
which ARMv6 CPU you are targeting (and to some extent, which version
of gcc you are using). If you have code which needs to be enabled for
any ARMv6 target then you may have to test multiple macros. For
example see the way in which openssl defines __ARM_ARCH__
https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h
Thank you very much for your insight, Andre !
I think I may have discovered a specific situation which is causing the
problem to occur for me. It seems it occurs because I am trying to
build a kernel module under the recipes-kernel directory in my custom
layer. A colleague pointed out to me
that meta/classes/module.bbclass explicitly unsets CFLAGS and a bunch of
other macros in this situation.
it wasn't clear if you were compiling external kmods. Now that sets it
straight.
Maybe I need to put in some custom shell syntax in my recipe, to export
__ARM_ARCH_6__ or to directly define the compiler macro when needed,
based on the value of the TARGET variable. I wonder if there is a
better recommended solution than this, though.
kernel modules are built using kernel flags for best results, thats why
you see that we do not enforce general cflags since they may be
enforcing userspace ABI options into kernel, which is not right. Further
more kernel build system constructs its own compiler commandline from
kbuild.
You could add something like CONFIG_CPU_32v6K=y or CONFIG_CPU_32v6=y
to your kernel .config and that should provide you with right flags
during your kernel module compilation step.
BTW, my kernel module contains conditionally-compiled code for
initializing the ARM PMU correctly for each CPU case.
- Steve
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto