Arm Multilib Question
joel at rtems.org
Fri Oct 11 14:15:43 UTC 2019
On Fri, Oct 11, 2019 at 8:55 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 11/10/2019 15:46, Joel Sherrill wrote:
> > Hi
> > I'm trying to find the right multilib for the ARM Deos BSP. They compile
> > their native
> > ARINC 653 applications with these:
> > arm-eabi-gcc -MP -MMD -nostdinc -gdwarf-2 -fno-exceptions
> > -mabi=aapcs-linux -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
> > -mthumb -mthumb-interwork -O0 -fno-threadsafe-statics
> > -fno-use-cxa-atexit -fno-rtti
> I am not sure if -mabi=aapcs-linux is a nop or dangerous. Why do they
> use this option.
I deleted this from the RTEMS builds. I recall determining it is the default
for us but don't hold me to that.
> The -mthumb-interwork is superfluous.
> The -fno-exceptions and -fno-rtti make more sense if you build libstdc++
> also with it.
They custom build their C++ support and I should have deleted those as
I am just concerned about CPU related C flags.
> > Neither arm-eabi nor arm-rtems will link this. arm-eabi picks a variant
> > for crtn0.o but doesn't seem to find a libm even though one is there in
> > the same multilib path and ends up with the math function undefined.
> > arm-rtems is just missing the multlib info as best I can tell.
> > error: /tmp/cc8zsaRc.o uses VFP register arguments, armtest does not
> > failed to merge target specific data of file /tmp/cc8zsaRc.o
> > I have attached my simple example. Do we have a multlib that should be
> > matching this or does one need to be added?
> > Assistance definitely appreciated.
> GCC 8, 9 and 10 are not supported by the ARM BSPs right now.
+1 I'm building with the gcc master so the patch can be against that if one
> You can try this with GCC 10:
> -mthumb -march=armv7-a+simd -mfloat-abi=hard
That definitely links! Thank you!
Is there something comparable for the gcc 7.4.1 we are actually using?
> Why do they use -mfpu=vfpv3-d16? This seems to be quite a non-standard
> ARMv7-A chip.
I don't know how they got to this. They don't have any custom ARM CPUs.
the same type of things we are used to -- Zynq, MPSoc, and the NXP
This is definitely something I will have to discuss with them.
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel