Re: [Xenomai] Floating point operations in kernel on powerpc

[Norbert Bukuli <norbert.bukuli@mediso.hu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you again for your kind help!
I am really sorry for the confusing question. Now we are compiling
kernel modules only. Afterwards we port our application from RTAI,
kernelspace to Xenomai, kernelspace will we port from kernelspace to
userspace.
I found what makes the problem. The CONFIG_CC_OPTIMIZE_FOR_SIZE kernel
option was set on. After I turned it off, the compilation was successful.
Thank you, once again!


On 2013-02-15 13:21, Philippe Gerum wrote:
> On 02/14/2013 08:56 AM, Norbert Bukuli wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Dear Mr Gerum,
>> 
>> let me respond your letter below.
>> 
>> On 2013-02-13 18:15, Philippe Gerum wrote:
>>> On 02/13/2013 04:49 PM, Norbert Bukuli wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 
>>>> Dear Mr Gerum,
>>>> 
>>>> thank you for your kind answer. As you can see in the
>>>> example code I do not call explicitly either _savefpr_XX or 
>>>> rthal_save_fpu and their restore counterparts. I only do
>>>> some floating point operations in a Xenomai domain kernel
>>>> thread. However the linker misses the routines mentioned
>>>> earlier. Are there linker flags to change this behaviour? One
>>>> important note, in the kernel configuration the hardware FPU
>>>> support is switched on. (CONFIG_XENO_HW_FPU=y)
>>> 
>>> -msoft-float with hw FPU looks suspicious.
>> - -msoft-float is defined by the kernel's make system, but if you
>> read the line further you can see, that I set the -mhard-float
>> compiler flag.
>> 
>> I don't understand why you
>>> mention C runtime libraries when building kernel modules
>>> either.
>> It is probably my bad english, sorry for that. I mentioned the c
>> runtime library, because there is a file a kernel source:
>> arch/powerpc/lib/crtsavres.S One can see in this file: "Based on
>> gcc/config/rs6000/crtsavres.asm from gcc".
>> 
>>> Building with eldk 5.2.1 for fpu-enabled 6xx cores can be done 
>>> with 
>>> eldk-5.2.1/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-gcc
>>>
>>>
>>>
>>
>>> 
from a stock eldk install.
>> I use eldk-switch for set the environmental variables
>> corresponding to the ELDK toolchain, and I use exactly the same
>> compiler: $ eldk-switch -r 5.2.1 powerpc $ which
>> powerpc-linux-gcc 
>> /opt/eldk-5.2.1/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-gcc
>>
>>
>>>
>>>
>> 
Actually, running fpu code in kernel space is a bad idea in the
>>> first place. Xenomai supports this for desperate situations
>>> when porting relic code absolutely requires it, but this is
>>> clearly something that should be avoided. You should really
>>> consider moving all that stuff to userland if the situation is
>>> not that desperate.
>>> 
>> 
>> Yes, I know, that is what we are working on. As I wrote it in my
>> first letter, we should port our application to Xenomai and run
>> it in userspace.
>> 
> 
> No, this does not look like so, which is exactly what makes your 
> questions quite confusing. You talk about porting to userland, and
> keep building kernel modules, which does not make much sense.
> 
> Meanwhile, I tried your test project, and successfully compiled
> it, which was expected reading the code:
> 
> {rpm@cobalt} make ARCH=powerpc CROSS_COMPILE=powerpc-linux- 
> KSRC=$HOME/git/ipipe modules make -C /home/rpm/git/ipipe
> M=/home/rpm/foo/4951215 modules make[1]: Entering directory
> `/home/rpm/git/ipipe' CC [M]  /home/rpm/foo/4951215/fpu_test.o In
> file included from /home/rpm/foo/4951215/fpu_test.c:4:0: 
> include/xenomai/native/task.h: In function 'rt_task_spawn': 
> include/xenomai/native/task.h:319:5: warning: 'rt_task_create' is 
> deprecated (declared at include/xenomai/native/task.h:252) 
> [-Wdeprecated-declarations] /home/rpm/foo/4951215/fpu_test.c: In
> function 'fpu_test_init': /home/rpm/foo/4951215/fpu_test.c:28:2:
> warning: 'rt_task_create' is deprecated (declared at
> include/xenomai/native/task.h:252) [-Wdeprecated-declarations] 
> Building modules, stage 2. MODPOST 1 modules CC
> /home/rpm/foo/4951215/fpu_test.mod.o LD [M]
> /home/rpm/foo/4951215/fpu_test.ko make[1]: Leaving directory
> `/home/rpm/git/ipipe'
> 
> So, as a matter of fact, I don't know where the problem could be,
> since I see no code those helpers could be referenced from.
> 

- -- 
Best regards,
Norbert Bukuli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHjjNAAoJEJEs22zQJ00SSLsIAJqwSi5NL+uBsRopuw3mBeNf
aHNut0qQsaK/yK8h3+B88TI/y6gvQWehzAMaosrO+fSWMfma30kiq10O7SDW9bmk
/zLicexwnXradW5qp6KcvQx5PWVtVBrXOl7n4vD15c0roxJyYUuO82Lb/jhkyrwn
xEFnbItHQ+tdbnwc6IYLjYZBDp4gp2FHqT/ZfWvMCshDKUxyrP63DjBzXTKT4qYq
U7anyrD2gb+KgQn73OfKpzTOI0p++cUFk+W8k6Sskvyep2WLiLVGpA+Xx/GXXjU4
QcnM6hPOMgNp1EUI6kZhA9ZlGPfABsIFEGAgH277GZrzo7HytWpjU/ueufmhWiE=
=c85i
-----END PGP SIGNATURE-----