[Buildroot] C double type problem - at91sam9263

[Buildroot] C double type problem - at91sam9263

[Richard Hardy]

Hi Everyone,

I am quite new to using buildroot and embedded linux systems in general.
However, I have managed to use buildroot to get a (nearly) working
system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc
v 0.9.29)

 

I have one annoying problem though. One of the packages I am compiling
from source uses C's "double" type, and this does not seem to be
behaving as I need it to.

 

I have created a simple example program:

 

...

int main (int argc, char *argv[])

{

double test;

test = 1;

fprintf(stderr, "Test double = %f.\n", test);

}

 

And the output that I see is:

 

Test double = 1000000.

 

 

I guess that this is due to one of the options, somewhere, in either the
Linux Kernel, uClibc or something else, but I don't know how to find out
which one. 

 

Can anyone point me in the right direction of where to look?

 

Thanks for your help,

 

Richard.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080804/8b13e62e/attachment.htm 

[Buildroot] C double type problem - at91sam9263

[John Voltz]

Do you get any warnings when compiling your test program? What happens if
you: test = 1.0;

I'm thinking maybe it's a casting problem.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080804/014d0417/attachment.htm 

[Buildroot] C double type problem - at91sam9263

[Hinko Kocevar]

Richard Hardy wrote:
> Hi Everyone,
> 
> I am quite new to using buildroot and embedded linux systems in general.
> However, I have managed to use buildroot to get a (nearly) working
> system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc
> v 0.9.29)
> 
>  
> 
> I have one annoying problem though. One of the packages I am compiling
> from source uses C's "double" type, and this does not seem to be
> behaving as I need it to.
> 
>  
> 
> I have created a simple example program:
> 
>  
> 
> ...
> 
> int main (int argc, char *argv[])
> 
> {
> 
> double test;
> 
> test = 1;
> 
> fprintf(stderr, "Test double = %f.\n", test);
> 
> }
> 
>  
> 
> And the output that I see is:
> 
>  
> 
> Test double = 1000000.
> 
>  
> 
>  
> 
> I guess that this is due to one of the options, somewhere, in either the
> Linux Kernel, uClibc or something else, but I don't know how to find out
> which one. 
> 
>  
> 
> Can anyone point me in the right direction of where to look?

I see it too on cris architecture. I think it is uClibc related, at least 0.9.29. 
I'll try to reproduce on x86..
IMHO only printf is buggy, otherwise doubles and floats seem to have correct value.

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] C double type problem - at91sam9263

[Richard Hardy]

> Do you get any warnings when compiling your test program? What happens
if
> you: test = 1.0;
> 
> I'm thinking maybe it's a casting problem.
> 
> John
> 

If I do:
test = 1.0;
fprintf(stderr, "Test double = %f.\n", test);

I get exactly the same results. i.e. it displays:
1000000

Richard.

[Buildroot] C double type problem - at91sam9263

[Richard Hardy]

> I see it too on cris architecture. I think it is uClibc related, at
least
> 0.9.29.
> I'll try to reproduce on x86..
> IMHO only printf is buggy, otherwise doubles and floats seem to have
> correct value.

When you say "doubles and floats seem to have correct value" how are you
testing them? I have tried using gdb to look at and set double values,
but I seem to get weird results. This is what led me to try to fprintf
the double values in the first place.

e.g. if I call a function with a double parameter set to "1.0", inside
the called function, gdb reports that parameter to have a value of
35532351778122413e-313. If I try to use gdb to "set" a double value I
get a segmentation fault. Integers seem to work ok.

Thanks,
Richard.

[Buildroot] C double type problem - at91sam9263

[Hinko Kocevar]

Richard Hardy wrote:
>> I see it too on cris architecture. I think it is uClibc related, at
> least
>> 0.9.29.
>> I'll try to reproduce on x86..
>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>> correct value.
> 
> When you say "doubles and floats seem to have correct value" how are you
> testing them? 

I put a loop in your test program and expected correct number of iterations.
test = 100;
fprintf(stderr, "Test double = %f.\n", test);
while (test)
{
	fprintf(stderr, "Test double = %f.\n", test);
	test -= 2;
}

This spins 50-times.
On cris toolchain with gcc 4.3.1, uClibc 0.9.29:
Test double = 100000000.
Test double = 98000000.
Test double = 96000000.
Test double = 94000000.
Test double = 92000000.
Test double = 90000000.
Test double = 88000000.
Test double = 86000000.
Test double = 84000000.
Test double = 82000000.
Test double = 80000000.
Test double = 78000000.
Test double = 76000000.
Test double = 74000000.
Test double = 72000000.
Test double = 70000000.
Test double = 68000000.
Test double = 66000000.
Test double = 64000000.
Test double = 62000000.
Test double = 60000000.
Test double = 58000000.
Test double = 56000000.
Test double = 54000000.
Test double = 52000000.
Test double = 50000000.
Test double = 48000000.
Test double = 46000000.
Test double = 44000000.
Test double = 42000000.
Test double = 40000000.
Test double = 38000000.
Test double = 36000000.
Test double = 34000000.
Test double = 32000000.
Test double = 30000000.
Test double = 28000000.
Test double = 26000000.
Test double = 24000000.
Test double = 22000000.
Test double = 20000000.
Test double = 18000000.
Test double = 16000000.
Test double = 14000000.
Test double = 12000000.
Test double = 10000000.
Test double = 8000000.
Test double = 6000000.
Test double = 4000000.
Test double = 2000000.

On i386 toolchain with gcc 4.3.1, uClibc 0.9.29:
Test double = 100.000000.
Test double = 98.000000.
Test double = 96.000000.
Test double = 94.000000.
Test double = 92.000000.
Test double = 90.000000.
Test double = 88.000000.
Test double = 86.000000.
Test double = 84.000000.
Test double = 82.000000.
Test double = 80.000000.
Test double = 78.000000.
Test double = 76.000000.
Test double = 74.000000.
Test double = 72.000000.
Test double = 70.000000.
Test double = 68.000000.
Test double = 66.000000.
Test double = 64.000000.
Test double = 62.000000.
Test double = 60.000000.
Test double = 58.000000.
Test double = 56.000000.
Test double = 54.000000.
Test double = 52.000000.
Test double = 50.000000.
Test double = 48.000000.
Test double = 46.000000.
Test double = 44.000000.
Test double = 42.000000.
Test double = 40.000000.
Test double = 38.000000.
Test double = 36.000000.
Test double = 34.000000.
Test double = 32.000000.
Test double = 30.000000.
Test double = 28.000000.
Test double = 26.000000.
Test double = 24.000000.
Test double = 22.000000.
Test double = 20.000000.
Test double = 18.000000.
Test double = 16.000000.
Test double = 14.000000.
Test double = 12.000000.
Test double = 10.000000.
Test double = 8.000000.
Test double = 6.000000.
Test double = 4.000000.
Test double = 2.000000.

> I have tried using gdb to look at and set double values,
> but I seem to get weird results. This is what led me to try to fprintf
> the double values in the first place.
> 
> e.g. if I call a function with a double parameter set to "1.0", inside
> the called function, gdb reports that parameter to have a value of
> 35532351778122413e-313. If I try to use gdb to "set" a double value I
> get a segmentation fault. Integers seem to work ok.
> 

I'll do tests with gdb(server) tomorrow, I can run the test program under gdbserver
but it won't stop at breakpoints when I set them ?!?.

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] C double type problem - at91sam9263

[Matthew Dombroski]

On Tue, Aug 5, 2008 at 2:16 AM, Hinko Kocevar
<hinko.kocevar@cetrtapot.si> wrote:
> Richard Hardy wrote:
>>> I see it too on cris architecture. I think it is uClibc related, at
>> least
>>> 0.9.29.
>>> I'll try to reproduce on x86..
>>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>>> correct value.
>>

I had this problem some time ago, as have others, and found the
solution to be disabling uClibc's locale support.
Not ideal, but at least you can display floats, dates, etc.

http://www.busybox.net/lists/buildroot/2007-March/002232.html
http://buildroot.uclibc.org/lists/buildroot/2008-June/008945.html
http://buildroot.uclibc.org/lists/buildroot/2008-April/008176.html

~Matthew

[Buildroot] C double type problem - at91sam9263

[Hinko Kocevar]

Matthew Dombroski wrote:
> On Tue, Aug 5, 2008 at 2:16 AM, Hinko Kocevar
> <hinko.kocevar@cetrtapot.si> wrote:
>> Richard Hardy wrote:
>>>> I see it too on cris architecture. I think it is uClibc related, at
>>> least
>>>> 0.9.29.
>>>> I'll try to reproduce on x86..
>>>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>>>> correct value.
> 
> I had this problem some time ago, as have others, and found the
> solution to be disabling uClibc's locale support.
> Not ideal, but at least you can display floats, dates, etc.
> 
> http://www.busybox.net/lists/buildroot/2007-March/002232.html
> http://buildroot.uclibc.org/lists/buildroot/2008-June/008945.html
> http://buildroot.uclibc.org/lists/buildroot/2008-April/008176.html
> 

Right.
I've confirmed that floats for cris architecture with uClibc without locale work.

But what about i386 toolchain with uClibc and locale enabled? It seem to work in my case.. I'll redo the test with clean buildroot just to be sure.


Best regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] C double type problem - at91sam9263

[Hinko Kocevar]

Hinko Kocevar wrote:

> 
> But what about i386 toolchain with uClibc and locale enabled? It seem to work in my case.. I'll redo the test with clean buildroot just to be sure.
> 

As stated above - i386 + uClibc 0.9.29 locale works fine when dealing with floats and date output is fine too.
Tested inside the chrooted busybox environment with:

$ /tmp/buildroot/build_i386/staging_dir/usr/bin/i386-linux-uclibc-gcc -static -O0 -ggdb3 test.c -o float.i386
$ cat test.c 
#include <stdio.h>
#include <string.h>

int main (int argc, char *argv[])
{
	double test;
	test = 1.0;
	fprintf(stderr, "Test double = %f.\n", test);
	
	test /= 100;
	fprintf(stderr, "Test double = %f.\n", test);

	test = 10;
	fprintf(stderr, "Test double = %f.\n", test);

	while (test)
	{
		fprintf(stderr, "Test double = %f.\n", test);
		test -= 2;
	}

	return 0;
}
$ sudo chroot ./root /bin/sh
/ $ ./float.i386 
Test double = 1.000000.
Test double = 0.010000.
Test double = 10.000000.
Test double = 10.000000.
Test double = 8.000000.
Test double = 6.000000.
Test double = 4.000000.
Test double = 2.000000.

/ $ set
HISTFILE='/home/hinkok/.ash_history'
HOME='/home/hinkok'
IFS=' 	
'
LOGNAME='root'
PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin'
PPID='25055'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHELL='/bin/bash'
SUDO_COMMAND='/bin/chroot ./root /bin/sh'
SUDO_GID='1000'
SUDO_UID='1000'
SUDO_USER='hinkok'
TERM='xterm'
USER='root'
_='./float.i386'




Maybe is the pregenerated locale data that is causing problems?? I'll test with own homebuilt locale data instead ..

Regards,
Hinko

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: br2.config
Url: http://busybox.net/lists/buildroot/attachments/20080805/7f0d2514/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: uClibc.config
Url: http://busybox.net/lists/buildroot/attachments/20080805/7f0d2514/attachment-0003.txt 

[Buildroot] C double type problem - at91sam9263

[Ulf Samuelsson]

----- Original Message ----- 
  From: Richard Hardy 
  To: buildroot at uclibc.org 
  Sent: Monday, August 04, 2008 12:29 PM
  Subject: [Buildroot] C double type problem - at91sam9263


  Hi Everyone,

  I am quite new to using buildroot and embedded linux systems in general. However, I have managed to use buildroot to get a (nearly) working system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc v 0.9.29)

   

  I have one annoying problem though. One of the packages I am compiling from source uses C's "double" type, and this does not seem to be behaving as I need it to.

   

  I have created a simple example program:

   

  .

  int main (int argc, char *argv[])

  {

  double test;

  test = 1;

  fprintf(stderr, "Test double = %f.\n", test);

  }

   



Should you not be using "%lf" instead of "%f" ?

   fprintf(stderr, "Test double = %lf.\n", test);

   fprintf(stderr, "Test double = %f.\n", test);

Best Regards
Ulf Samuelsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080805/858a43c6/attachment.htm 

[Buildroot] C double type problem - at91sam9263

[Richard Hardy]

> -----Original Message-----
> From: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com]
> Sent: 05 August 2008 12:21
> To: Richard Hardy; buildroot at uclibc.org
> Subject: Re: [Buildroot] C double type problem - at91sam9263
> 
> ----- Original Message -----
> 
> 	From: Richard Hardy <mailto:richardh@oakleafconsultancy.com>
> 	To: buildroot at uclibc.org
> 	Sent: Monday, August 04, 2008 12:29 PM
> 	Subject: [Buildroot] C double type problem - at91sam9263
> 
> 
> 
> 	Hi Everyone,
> 
> 	I am quite new to using buildroot and embedded linux systems in
> general. However, I have managed to use buildroot to get a (nearly)
> working system up and running for an at91sam9263 board. (kernel v
2.6.22,
> uClibc v 0.9.29)
> 
> 
> 
> 	I have one annoying problem though. One of the packages I am
> compiling from source uses C's "double" type, and this does not seem
to be
> behaving as I need it to.
> 
> 
> 
> 	I have created a simple example program:
> 
> 
> 
> 	...
> 
> 	int main (int argc, char *argv[])
> 
> 	{
> 
> 	double test;
> 
> 	test = 1;
> 
> 	fprintf(stderr, "Test double = %f.\n", test);
> 
> 	}
> 
> 
> 
> 
> 
> Should you not be using "%lf" instead of "%f" ?
> 
>    fprintf(stderr, "Test double = %lf.\n", test);
> 
>    fprintf(stderr, "Test double = %f.\n", test);
> 
> Best Regards
> Ulf Samuelsson
> 

Yes, you are right. But, it makes no difference to the output.

Best regards,
Richard.

[Buildroot] C double type problem - at91sam9263

[Christopher Taylor]

Could this be related to how you are compiling the code, uclibc, and
the OS as far as endian-ness ?  big vs middle vs little endian?

just a thought.  I've been burned by the middle-endianness on the
arm9261.  Last I looked there were some defects in how buildroot took
your parameters and implemented them in uClibc and the kernel (I seem
to remeber there was a bug in uClibc that buildroot incorrectly worked
around, but I wouldn't swear to it)

-Chris

On Tue, Aug 5, 2008 at 6:51 AM, Richard Hardy
<richardh@oakleafconsultancy.com> wrote:
>
>
>> -----Original Message-----
>> From: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com]
>> Sent: 05 August 2008 12:21
>> To: Richard Hardy; buildroot at uclibc.org
>> Subject: Re: [Buildroot] C double type problem - at91sam9263
>>
>> ----- Original Message -----
>>
>>       From: Richard Hardy <mailto:richardh@oakleafconsultancy.com>
>>       To: buildroot at uclibc.org
>>       Sent: Monday, August 04, 2008 12:29 PM
>>       Subject: [Buildroot] C double type problem - at91sam9263
>>
>>
>>
>>       Hi Everyone,
>>
>>       I am quite new to using buildroot and embedded linux systems in
>> general. However, I have managed to use buildroot to get a (nearly)
>> working system up and running for an at91sam9263 board. (kernel v
> 2.6.22,
>> uClibc v 0.9.29)
>>
>>
>>
>>       I have one annoying problem though. One of the packages I am
>> compiling from source uses C's "double" type, and this does not seem
> to be
>> behaving as I need it to.
>>
>>
>>
>>       I have created a simple example program:
>>
>>
>>
>>       ...
>>
>>       int main (int argc, char *argv[])
>>
>>       {
>>
>>       double test;
>>
>>       test = 1;
>>
>>       fprintf(stderr, "Test double = %f.\n", test);
>>
>>       }
>>
>>
>>
>>
>>
>> Should you not be using "%lf" instead of "%f" ?
>>
>>    fprintf(stderr, "Test double = %lf.\n", test);
>>
>>    fprintf(stderr, "Test double = %f.\n", test);
>>
>> Best Regards
>> Ulf Samuelsson
>>
>
> Yes, you are right. But, it makes no difference to the output.
>
> Best regards,
> Richard.
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>

[Buildroot] C double type problem - at91sam9263

[Richard Hardy]

> -----Original Message-----
> From: Christopher Taylor [mailto:chtaylo3 at gmail.com]
> Sent: 05 August 2008 18:38
> To: Richard Hardy
> Cc: Ulf Samuelsson; buildroot at uclibc.org
> Subject: Re: [Buildroot] C double type problem - at91sam9263
> 
> Could this be related to how you are compiling the code, uclibc, and
> the OS as far as endian-ness ?  big vs middle vs little endian?
> 
> just a thought.  I've been burned by the middle-endianness on the
> arm9261.  Last I looked there were some defects in how buildroot took
> your parameters and implemented them in uClibc and the kernel (I seem
> to remeber there was a bug in uClibc that buildroot incorrectly worked
> around, but I wouldn't swear to it)
> 
> -Chris
> 

Thanks very much for everyone who has given me some hints so far. I
think that, as suggested, the fprintf problem is an output problem
(rather than storage). I am sort-of ignoring that for the time being.

However, the reason that I was trying to print out double values in the
first place was that I am getting lots of segmentation faults when I do
calculations involving int64_t and double values. 

I am using arm-linux-gcc v4.2.1., compiled on an intel Linux box to run
on an atmel at91sam9263. 

For example, one problem I found was that I was getting stack
corruptions when using "-Os" as a compiler option in (some) functions
that were being passed int64_t and double values. I fixed that by using
"-O0" instead. 

However, I am getting lots of other really weird segmentation faults
when I run the compiled program, which I am having to work around one by
one (I am trying to cross-compile and use ffmpeg which does lots of
complicated internal calculations for playing mpeg files).

Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
anyone suggest whether I might be better to try another version (ideally
one that Buildroot supports), and if so, which one?

Thanks again,
Richard.

[Buildroot] C double type problem - at91sam9263

[Hinko Kocevar]

Richard Hardy wrote:

> I am using arm-linux-gcc v4.2.1., compiled on an intel Linux box to run
> on an atmel at91sam9263. 
> 
> For example, one problem I found was that I was getting stack
> corruptions when using "-Os" as a compiler option in (some) functions
> that were being passed int64_t and double values. I fixed that by using
> "-O0" instead. 
> 

That sounds like a compiler problem...

> However, I am getting lots of other really weird segmentation faults
> when I run the compiled program, which I am having to work around one by
> one (I am trying to cross-compile and use ffmpeg which does lots of
> complicated internal calculations for playing mpeg files).
> 
> Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
> anyone suggest whether I might be better to try another version (ideally
> one that Buildroot supports), and if so, which one?

I guess you would be better off using latest compiler available in 4.2.x series - 4.2.3 or 4.2.4 that is. I had a lot of issues with different gcc versions for cris architecture (internal compiler errors, segafaults, etc.) and ended up using 4.3.1 that does the job for now ;)

my 2 c..

-- 
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si

[Buildroot] C double type problem - at91sam9263

[Ulf Samuelsson]

> Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
> anyone suggest whether I might be better to try another version (ideally
> one that Buildroot supports), and if so, which one?

Try using -O2.
Somewhere in a remote part of my brain it says that
you want this for the kernel.
Maybe applications are affected as well.

Best Regards
Ulf Samuelsson


Thanks again,
Richard.