[Xenomai] Floating point operations in kernel on powerpc

[Xenomai] Floating point operations in kernel on powerpc

[Norbert Bukuli]

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

Dear List Members,

First of all, this will be a newbie question, sorry for it.
Shortly, I have to port an old RTAI based kernelspace application to
Xenomai userpace. This application uses FPU so we compile it hard
float support. First step of the porting is switching the real-time
extension. I am done with this, however I have some compilation warnings:
WARNING: "_restfpr_22_x" [app.ko] undefined!
WARNING: "_restfpr_29_x" [app.ko] undefined!
WARNING: "_savefpr_22" [app.ko] undefined!
WARNING: "_savefpr_29" [app.ko] undefined!

I reproduced these warnings with the following example kernel module:
http://pastebin.com/AAehcivx

The corresponding Kbuild is:

obj-m := fpu_test.o
ccflags-y += -Iinclude/xenomai -Iinclude/xenomai/posix -mhard-float

As I see, the missing functions should be in the C runtime library,
however the kernel library (arch/powerpc/lib/crtsavres.S) contains
only save/restore macros for general purpose registers. On the other
hand, the Xenomai extensions provides kernelspace FPU facility and the
T_FPU flag was turned on rt_task_create().
So, my question is, how can I eliminate this problem?

The environment is the following:
Toolchain: ELDK-5.2.1, powerpc, hard float.
Kernel: linux-v3.2.21
Xenomai: v2.6.1

Any suggestion is highly appreciated. Thank you in advance!

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

iQEcBAEBAgAGBQJRG5TkAAoJEJEs22zQJ00S86IIAIh0vYdLf5++r+0EZSkSGGD+
Mui9k9h4huRmUo31H9rWMJvU/DkJHAKrvoR/QBpQ1L6ty6xyeOoYhwzpEbW9e9TO
uy9nxBeB3ORg6RFV6NLKaP6iifgifYJKkT89mEjts8hbXNoRyxZHJUNJuQtDNh45
JB3EuGKbjB5ItISXJupeKE4CXGMRHKxcHBiM3l1Nxq+zwrO+/CyGWtO+ZjWzEN4/
fiWIBMm3g/p82+KxTqTQLmmOA0/0aAZcO02mw/v8/dPm8Ty+K9jB0cIsakPifehm
gDUVlg1r/uNEaj4KVc0exE6zdiWwhIq3brYAxfzbCeEpc4b+MeFDNyggYE8vi2M=
=FKk7
-----END PGP SIGNATURE-----

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

[Philippe Gerum]

On 02/13/2013 02:28 PM, Norbert Bukuli wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear List Members,
>
> First of all, this will be a newbie question, sorry for it.
> Shortly, I have to port an old RTAI based kernelspace application to
> Xenomai userpace. This application uses FPU so we compile it hard
> float support. First step of the porting is switching the real-time
> extension. I am done with this, however I have some compilation warnings:
> WARNING: "_restfpr_22_x" [app.ko] undefined!
> WARNING: "_restfpr_29_x" [app.ko] undefined!
> WARNING: "_savefpr_22" [app.ko] undefined!
> WARNING: "_savefpr_29" [app.ko] undefined!
>
> I reproduced these warnings with the following example kernel module:
> http://pastebin.com/AAehcivx
>
> The corresponding Kbuild is:
>
> obj-m := fpu_test.o
> ccflags-y += -Iinclude/xenomai -Iinclude/xenomai/posix -mhard-float
>
> As I see, the missing functions should be in the C runtime library,
> however the kernel library (arch/powerpc/lib/crtsavres.S) contains
> only save/restore macros for general purpose registers. On the other
> hand, the Xenomai extensions provides kernelspace FPU facility and the
> T_FPU flag was turned on rt_task_create().
> So, my question is, how can I eliminate this problem?
>

Xenomai's context switching code does the necessary housekeeping to 
save/restore fprs. You don't have to call these routines.

-- 
Philippe.

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

[Norbert Bukuli]

-----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)


Probably snippets of the compilation output can help:
Compilation:
  powerpc-linux-gcc -m32
-
-Wp,-MD,/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/.fpu_test.o.d
 -nostdinc -isystem
/opt/eldk-5.2.1/powerpc/sysroots/i686-eldk-linux/usr/lib/powerpc-linux/gcc/powerpc-linux/4.6.4/include
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc/include
- -Iarch/powerpc/include/generated -Iinclude
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include
- -include
/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/linux/kconfig.h

-
-I/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test
- -D__KERNEL__
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc
- -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
- -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
- -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float
- -pipe
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc
- -Iarch/powerpc -ffixed-r2 -mmultiple -mno-altivec -mno-spe -mspe=no
- -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mcpu=powerpc
- -Wa,-maltivec -Wframe-larger-than=1024 -fno-stack-protector
- -Wno-unused-but-set-variable -fomit-frame-pointer
- -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
- -fconserve-stack -DCC_HAVE_ASM_GOTO
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/xenomai
- -Iinclude/xenomai
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/xenomai/posix
- -Iinclude/xenomai/posix -mhard-float  -DMODULE  -D"KBUILD_STR(s)=#s"
- -D"KBUILD_BASENAME=KBUILD_STR(fpu_test)"
- -D"KBUILD_MODNAME=KBUILD_STR(fpu_test)" -c -o
/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/fpu_test.o
/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/fpu_test.c

Link:
  powerpc-linux-gcc -m32
-
-Wp,-MD,/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/.fpu_test.mod.o.d
 -nostdinc -isystem
/opt/eldk-5.2.1/powerpc/sysroots/i686-eldk-linux/usr/lib/powerpc-linux/gcc/powerpc-linux/4.6.4/include
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc/include
- -Iarch/powerpc/include/generated -Iinclude
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include
- -include
/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/linux/kconfig.h

-
-I/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test
- -D__KERNEL__
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc
- -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
- -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
- -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float
- -pipe
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/arch/powerpc
- -Iarch/powerpc -ffixed-r2 -mmultiple -mno-altivec -mno-spe -mspe=no
- -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mcpu=powerpc
- -Wa,-maltivec -Wframe-larger-than=1024 -fno-stack-protector
- -Wno-unused-but-set-variable -fomit-frame-pointer
- -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
- -fconserve-stack -DCC_HAVE_ASM_GOTO
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/xenomai
- -Iinclude/xenomai
-
-I/home/bukulin/munka/gantry/Framework/src/Kernel/linux-gccb-v3.2.21_gccb.6/include/xenomai/posix
- -Iinclude/xenomai/posix -mhard-float  -D"KBUILD_STR(s)=#s"
- -D"KBUILD_BASENAME=KBUILD_STR(fpu_test.mod)"
- -D"KBUILD_MODNAME=KBUILD_STR(fpu_test)" -DMODULE  -c -o
/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/fpu_test.mod.o
/home/bukulin/munka/gantry/Application/gantry/gantry-source/Documentation/snippets/fpu_test/fpu_test.mod.c


Thank you!

On 2013-02-13 14:45, Philippe Gerum wrote:
> On 02/13/2013 02:28 PM, Norbert Bukuli wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Dear List Members,
>> 
>> First of all, this will be a newbie question, sorry for it. 
>> Shortly, I have to port an old RTAI based kernelspace
>> application to Xenomai userpace. This application uses FPU so we
>> compile it hard float support. First step of the porting is
>> switching the real-time extension. I am done with this, however I
>> have some compilation warnings: WARNING: "_restfpr_22_x"
>> [app.ko] undefined! WARNING: "_restfpr_29_x" [app.ko] undefined!
>> WARNING: "_savefpr_22" [app.ko] undefined! WARNING: "_savefpr_29"
>> [app.ko] undefined!
>> 
>> I reproduced these warnings with the following example kernel 
>> module: http://pastebin.com/AAehcivx
>> 
>> The corresponding Kbuild is:
>> 
>> obj-m := fpu_test.o ccflags-y += -Iinclude/xenomai 
>> -Iinclude/xenomai/posix -mhard-float
>> 
>> As I see, the missing functions should be in the C runtime 
>> library, however the kernel library 
>> (arch/powerpc/lib/crtsavres.S) contains only save/restore macros 
>> for general purpose registers. On the other hand, the Xenomai 
>> extensions provides kernelspace FPU facility and the T_FPU flag 
>> was turned on rt_task_create(). So, my question is, how can I 
>> eliminate this problem?
>> 
> 
> Xenomai's context switching code does the necessary housekeeping to
> save/restore fprs. You don't have to call these routines.
> 

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

iQEcBAEBAgAGBQJRG7YOAAoJEJEs22zQJ00S6+4H+wVDpKCnDdiYpULaGNO8ls7O
9AzCQuj9QKOvWm3hFPfE1dJrclaDRu0JJKIHLl+Exxluo05+wN7/veRBuNtQQRnB
sq3QFq0Bbo3P/s0ihqSQCuFiB70666uSD73p4Tlct8juvffnDvw4EhwMU9RQzoNW
KcDw488/YdwBxy7hpn5qqoEDuu+55NiKn/kH5fRpnuvBq1gKQ1CTVd6WLLXypjcQ
BgNzAoQyaKKx+iavfPXjIZ6ElJpTwX+ON0wwh8zXaSTy0WTsBYlR9xYhQgMA51jI
3rYePEQZPs1kqSHaj4cKyZyfIpuH/lYmUc3w7cQLyCA+iK5Le55L+adFzQIOykE=
=UmzM
-----END PGP SIGNATURE-----

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

[Philippe Gerum]

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. I don't understand why you 
mention C runtime libraries when building kernel modules either. 
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.

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.

-- 
Philippe.

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

[Norbert Bukuli]

-----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.

If it can help here is the test project:
https://gist.github.com/bukulin/4951215
(At the compilation the kernel build directory should be defined with
KSRC=<kernel build directory>)

Thank you four your help, again!

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

iQEcBAEBAgAGBQJRHJicAAoJEJEs22zQJ00SVDsH/jseNB7qxQiK0ZrcejY0QEJx
GhijebXtI7SxMbDQECYsb6+pEJYdKGtVRNuOQgSdinwe6EM66cUxWUyV4rF++WXu
9jOVlpl5BJF+c0s3S2n+bmmcstNz0Lct0ZE8yhPrDgO4nmk6YjTCYmixplXoeDOx
y3qves9JHSI4tvCMa/P0MDf4XmKRjPviCUadwihx/kwQjt4wxcXj7DOJcacgw/6V
9HSJFKUAk4N7/eV0sNjQWB08hDQJME74cdZ++0lf0llmUh2AQh7AC3LJN4RYR3hO
RGxSezF4n0NhUbEFYdY9U7Rzj26GasRKYTsUQ2Z/OAPGZSkHhIIIBIevb4rMkHI=
=ZtY5
-----END PGP SIGNATURE-----

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

[Norbert Bukuli]

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

This problem is still not resolved, so any suggestion or idea is
highly appreciated!
Thank you in advance!

On 2013-02-14 08:56, Norbert Bukuli wrote:
> 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.
> 
> If it can help here is the test project: 
> https://gist.github.com/bukulin/4951215 (At the compilation the
> kernel build directory should be defined with KSRC=<kernel build
> directory>)
> 
> Thank you four your help, again!
> 
> 
> _______________________________________________ Xenomai mailing
> list Xenomai@xenomai.org 
> http://www.xenomai.org/mailman/listinfo/xenomai
> 

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

iQEcBAEBAgAGBQJRHQKXAAoJEJEs22zQJ00SLYoH/3rS1nwHS7sy/RvD1CVfQPpd
Q0sYm1pxPqQlmVrwwG7onVrViaSBDLYa1zO6NOGdJ6jX03XoOLjQWchqyUYnHqrN
6ntExf1PPwn6ppm0mmrZxgw0hIsjjjWFrYOAAW5m59ZW4HmjJu3KdRnQ2xmEfOhy
L473TW1Kr92oO9djRwY28vn3TivkwgEdRJ4L5nBGG8t2nyR389mmNtEZ72s3E5Po
T8wWk2wzTAek18LC8XshTn4pN0u7VdAPiLmsEHG7cQJ+BxL1LrcB91eX1BulkCDM
A0AyFYZPDkNJUw18RKa7UeE1T8iRdLl7on6XFqt3bvchxPL9KCZQLDoZqUqRHxw=
=BdIz
-----END PGP SIGNATURE-----

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

[Gilles Chanteperdrix]

On 02/14/2013 04:28 PM, Norbert Bukuli wrote:

> This problem is still not resolved, so any suggestion or idea is
> highly appreciated!
> Thank you in advance!


You have two choices:
- try and spend the time reducing the kernel-space code to the bare
mininimum which produces references to this two functions, and
understand what they are used for, then throw away the result of this
work once you end-up porting your code to user-space
- ignore the uninteresting and obsolete issues you have when using FPU
in kernel-sapce and directly port your code to user-space.

-- 
                                                                Gilles.

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Norbert Bukuli]

-----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-----

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

[Philippe Gerum]

On 02/15/2013 02:31 PM, Norbert Bukuli wrote:
> -----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.

I guess you are referring to that issue brought in by gcc releases >= 4.4.x?
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg17189.html
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html

It looks like the suggested kernel patch to fix it did not make its way 
to the kernel. Bottom line is that it's not fpu related actually. This 
is definitely good material for the Xenomai wiki.

-- 
Philippe.

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

[Norbert Bukuli]

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



On 2013-02-15 15:51, Philippe Gerum wrote:
> On 02/15/2013 02:31 PM, Norbert Bukuli wrote:
>> -----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.
> 
> I guess you are referring to that issue brought in by gcc releases
> >= 4.4.x? 
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg17189.html
>
> 
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
> 
Yes, that was the problem, definitely.

> It looks like the suggested kernel patch to fix it did not make its
> way to the kernel. Bottom line is that it's not fpu related
> actually. This is definitely good material for the Xenomai wiki.
> 

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

iQEcBAEBAgAGBQJRHlMsAAoJEJEs22zQJ00Su18IALszpx85WwK8kR7U/kgRg9ex
Y4Fod11O+erU/dRpAwVhvxK8mK+HO06m0GARAadkDUjQJjFmjOUyEs6p71oFGRkQ
+l6/IJOnUCVOjOVO5JLhYjsyoeh8VnQtMcI9IUIvoukSNPngyr41UMOTFp7traXj
Mdnjbt2Spk8CY3u2JX28SbfzEjSBmmnQajTJy9mOtkrpXyRt4D6Pbsyb4M1gVD5N
LbCX09/Vj6B9yJrWk1bvKxm7Lbbin2O896k/tTTh5ZxH0HyS9ZnTLrKKDWN65ZMq
sJZg84cN23U8vv3WJVwhdRmXvZ8ub8eLjM9R1gmK89F7v4+Arwsou8VQv2EBbjY=
=yprj
-----END PGP SIGNATURE-----