scanf doesn't work

[Leonitis]

I'm pretty sure this is an issue with the cross-compiler (sorry if it's not).

I successfully built a cross-compiler for the ARM with crosstool-ng and everything works fine. However, when I want to get user float input with scanf(), it misses the negative sign, even though it works fine with integers. For example, 3.5 and -3.5 are both read in as 3.5.

I compiled the same test program for my desktop and it works correctly (so it's not because of incorrect usage of scanf).

How do I fix this? Is this a bug in glibc?

Thanks in advance!

[Yann E. MORIN]

On Thursday 18 June 2009 16:16:39 Leonitis wrote:
> I successfully built a cross-compiler for the ARM with crosstool-ng and
> everything works fine. However, when I want to get user float input with
> scanf(), it misses the negative sign, even though it works fine with
> integers. For example, 3.5 and -3.5 are both read in as 3.5.

Works for me with:
linux headers 2.6.29.4
gmp-4.2.4
mpfr-2.4.1
binutils-2.19.1
gcc-4.3.3
glibc-2.9 dated 2009-06-18, with the ports addon.

prompt> cat >ess.c <<_EOF_
#include <stdio.h>
#include <stdlib.h>

int main( int argc,
          char** argv )
{
    float f;

    scanf( "%f", &f );
    printf( "f='%f'", f );
    if( f < 0 )      { printf( "is negative\n" ); }
    else if( f > 0 ) { printf( "is positive\n" ); }
    else             { printf( "is null\n" ); }
    return 0;
}
_EOF_
prompt> armeb-unknown-linux-gnueabi-gcc -o ess ess.c
prompt> qemu-armeb -L [...]/armeb-unknown-linux-gnueabi/sys-root/ ./ess
-3.5
f='-3.500000' is negative
prompt> qemu-armeb -L [...]/armeb-unknown-linux-gnueabi/sys-root/ ./ess
3.5
f='3.500000' is positive
prompt> qemu-armeb -L [...]/armeb-unknown-linux-gnueabi/sys-root/ ./ess
0
f='0.000000' is null

Didn't try with ARM litle endian, though...

What's your toolchain setup?

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


--
For unsubscribe information see http://sourceware.org/lists.html#faq

[nyet]

On Thu, Jun 18, 2009 at 10:51:01AM -0700, Yann E. MORIN wrote:
> On Thursday 18 June 2009 16:16:39 Leonitis wrote:
> > I successfully built a cross-compiler for the ARM with crosstool-ng and
> > everything works fine. However, when I want to get user float input with
> > scanf(), it misses the negative sign, even though it works fine with
> > integers. For example, 3.5 and -3.5 are both read in as 3.5.

If he is used to the way x86 compilers/cpus handle signed data storage,
maybe he is doing a questionable cast someplace.

There are signed/unsigned casts that work for x86 that do not work for,
say, ppc and arm.

--
Nye Liu
nliu@...
[phone]x248
[phone] fax

"Who would be stupid enough to quote a fictitious character?"
        -- Don Quixote

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[martinwguy]

On 6/18/09, Leonitis <rubixqb@...> wrote:
> How do I fix this? Is this a bug in glibc?

Very unlikely. Please provide a minimal test program that "does not
work" for you.

    M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Leonitis]

Thanks everyone for responding so fast!

My toolchain setup is the standard arm-unknown-linux-gnu configuration:
kernel headers version 2.6.29
binutils version 2.19.1
gcc 4.3.2
glibc 2.9
etc..

My test code is:
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv)
{
        float a;
        int b;

        printf("Input float: ");
        scanf("%f", &a);
        printf("Input is: %f\n", a);

        printf("\nInput integer: ");
        scanf("%d", &b);
        printf("Input is: %d\n", b);

        return 0;
}

My output is:
Input float: -3.5
Input is: 3.500000

Input integer: -3
Input is: -3

I'm not too familiar with what the Linux headers are for, but the kernel version on the evaluation board is 2.6.20. Could that be the problem?

[martinwguy]

On 6/19/09, Leonitis <rubixqb@...> wrote:
> I'm not too familiar with what the Linux headers are for, but the kernel
> version on the evaluation board is 2.6.20. Could that be the problem?

I can't reproduce this problem, but one way to make it go away might be to use
arm-unknown-linux-gnueabi and compile your kernel with USE_EABI set.
You will also need to replace your rootf with one compiled using EABI
as this is an incompatible change.

Among other things, this changes the way floating point is performed
from kernel emulation of an extinct FPU's hardware instructions to
using a soft tloat library, which not only changes the FP code in
glibc and its execution mechanism, but also makes floating point
calculations work 11 times faster (yes, 11) as well as enabling you to
use your FPU if any for a further 2 to 5 times speedup in FP. All the
main distros are switching to EABI too, which will future-proof your
work.
See wiki.debian.org/ArmEabiPort for gory details and HOWTOs

Or you can try to isolate the exact cause of your bug...

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Leonitis]

Thanks for the suggestion.

I can't really put in the time for doing that as my work is related to something else. I want to use scanf() to conduct tests on the ARM processor.

However, floating point computations are performed correctly. If I set
float a = -3.5;
then it gets registered properly as a negative. I'm not sure that this is a problem with the floating point processing.

On a side note, is it not enough to select "soft float" in the configuration to avoid the wasted hardware interrupts to the "extinct" FPU?

Back to the problem, how could I approach isolating this bug, if it is indeed a problem with scanf() (or is it almost certainly not to do with scanf)?

Thanks!

[Yann E. MORIN]

All,

On Friday 19 June 2009 16:04:51 Martin Guy wrote:
> I can't reproduce this problem, but one way to make it go away might be to use
> arm-unknown-linux-gnueabi and compile your kernel with USE_EABI set.
> You will also need to replace your rootf with one compiled using EABI
> as this is an incompatible change.

Or activate support for OABI in the kernel...
Of course, this {w,c}ould lead to having two libc: one EABI, and one OABI.
And would require carefully linking the /new/ software against the EABI one.
And many other weird stuff could happen.

> also makes floating point
> calculations work 11 times faster (yes, 11)

Yep, it does! :-)

> as well as enabling you to
> use your FPU if any for a further 2 to 5 times speedup in FP.

Hmmm... I don't have any FPU, but I would have thought than an FPU would
speed up float calculations by more than a mere 5x. I will have to make
use of the NEON extensions on my OMAP3530 to check. Low prio, though...

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Yann E. MORIN]

Leonitis,
All,

On Friday 19 June 2009 15:33:54 Leonitis wrote:
> My toolchain setup is the standard arm-unknown-linux-gnu configuration:
> kernel headers version 2.6.29
> binutils version 2.19.1
> gcc 4.3.2
> glibc 2.9
> etc..
>
> My test code is:
[--SNIP--]

Can't reproduce here either, with your own code snippet stored
in ess.c :
prompt> arm-unknown-linux-gnu-gcc -o ess ess.c

prompt> qemu-arm -L [...]/arm-unknown-linux-gnu/sys-root ./ess
Input float: -3.5
Input is: -3.500000
[...]

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


--
For unsubscribe information see http://sourceware.org/lists.html#faq

[martinwguy]

On 6/19/09, Leonitis <rubixqb@...> wrote:
> On a side note, is it not enough to select "soft float" in the configuration
> to avoid the wasted hardware interrupts to the "extinct" FPU?

With the old ABI, binaries compiled with hard float cannot be linked
with those compiled with soft float so you need an entire new set of
libraries too. For example, FP function parameters and return values
are passed in FPU registers. Read the wiki page I pointed at

> Back to the problem, how could I approach isolating this bug, if it is
> indeed a problem with scanf() (or is it almost certainly not to do with
> scanf)?

The usual way: divide the problem space in two, devise a test that
tells you which half the problem lies in. Repeat :)

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Khem Raj-3]

On Fri, Jun 19, 2009 at 6:33 AM, Leonitis<rubixqb@...> wrote:

>
> Thanks everyone for responding so fast!
>
> My toolchain setup is the standard arm-unknown-linux-gnu configuration:
> kernel headers version 2.6.29
> binutils version 2.19.1
> gcc 4.3.2
> glibc 2.9
> etc..
>
> My test code is:
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int argc, char** argv)
> {
>        float a;
>        int b;
>
>        printf("Input float: ");
>        scanf("%f", &a);
>        printf("Input is: %f\n", a);
>
>        printf("\nInput integer: ");
>        scanf("%d", &b);
>        printf("Input is: %d\n", b);
>
>        return 0;
> }
>
> My output is:
> Input float: -3.5
> Input is: 3.500000
>
> Input integer: -3
> Input is: -3
>
> I'm not too familiar with what the Linux headers are for, but the kernel
> version on the evaluation board is 2.6.20. Could that be the problem?

I dont suspect kernel versions to be a problem here.
Could you try compile/run it as a static binary? if you have not done so.
It could just be a misatch of libraries on your system Vs the libraries
you are using to develop/compile the testcase

Thanks

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Leonitis]

Khem Raj-3 wrote:

Could you try compile/run it as a static binary? if you have not done so.
It could just be a misatch of libraries on your system Vs the libraries
you are using to develop/compile the testcase

I have not done that before. After setting the "-static" flag (that's how you do it, right?),
I get "FATAL: kernel too old" followed by a seg fault.

Am I doing something wrong, or does this mean that the static binary is incompatible with the target kernel?

Thanks!

[Khem Raj-3]

On 6/26/09, Leonitis <rubixqb@...> wrote:

>
>
> Khem Raj-3 wrote:
>>
>> Could you try compile/run it as a static binary? if you have not done so.
>> It could just be a misatch of libraries on your system Vs the libraries
>> you are using to develop/compile the testcase
>>
>
> I have not done that before. After setting the "-static" flag (that's how
> you do it, right?),
> I get "FATAL: kernel too old" followed by a seg fault.

probably the glibc against which you linked is compiled with --enable-kernel
equal to a version number which is larger than the actual version you
are running
on the target. Check the option passed to configure for glibc when you
built the toolchain

Thanks

-Khem

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[Yann E. MORIN]

Leonitis, Khem,
All,

On Saturday 27 June 2009 02:25:48 Khem Raj wrote:
> On 6/26/09, Leonitis <rubixqb@...> wrote:
> > I have not done that before. After setting the "-static" flag (that's how
> > you do it, right?),
> > I get "FATAL: kernel too old" followed by a seg fault.
> probably the glibc against which you linked is compiled with --enable-kernel
> equal to a version number which is larger than the actual version you
> are running
> on the target. Check the option passed to configure for glibc when you
> built the toolchain

The user can set crosstool-NG to handle --enable-kernel in one of:
(1) set it to the same value as the kernel headers version  (default)
(2) set it to a specific value
(3) leave {,e}glibc ./configure decide by itself

Of course, if you use (1), it is strongly advised that you do use the
headers from the kernel that will actually run on the target! If you
run 2.6.0, and you use headers from 2.6.31-rc1, then it's borked.

BTW, the default is (1) to optimise-out as much legacy support code, to
gain space and efficiency (no run-time check of the kernel version).

Regards,
Yann E. MORIN

--
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


--
For unsubscribe information see http://sourceware.org/lists.html#faq