tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Segmentation Faults and test failures on ARM (Raspbia


From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Segmentation Faults and test failures on ARM (Raspbian/Raspberry Pi)
Date: Wed, 23 Jan 2013 22:48:02 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Le mercredi 23 janvier 2013 21:06:14, vous avez écrit :
> Hi Thomas:
> 
> I will try that commit soon, maybe tonight EST.
> 
> In the meantime, I have uncovered a few more parameters of the problem.
> 
> Now tried it on a BeagleBone (TI OMAP Arm processor) instead of a Raspberry
> Pi.
> 
> address@hidden:/var/log/tinycc# uname -a
> Linux beaglebone 3.2.5+ #1 Mon Feb 13 19:22:44 CET 2012 armv7l GNU/Linux
> 
> No Segmentation Faults so far, unlike the Pi, where tests under #40 would
> fail intermittently, perhaps every 3 to 5 times.

I thought about something arch specific since it would explain why I don't 
have the bug in qemu and in my own ARM laptop but have occasional segfault in 
some other machines I tried.

> Still getting the problem with stdio, however.  EOF is never detected
> apparently.  So I rewrote a version of the 40_stdio.c test as follows:
> 
> <snip>
>    fprintf ( stderr, "Staring fgetc test..." ) ;
> 
>    char InChar;
>    char ShowChar;
>    f = fopen("fred.txt", "r");
>    InChar = fgetc ( f ) ;
>    while (  ! feof ( f ) )
>    {
>       ShowChar = InChar;
>       if (ShowChar < ' ')
>          ShowChar = '.';
> 
>       printf("ch: %d '%c'\n", InChar, ShowChar);
>       InChar = fgetc ( f ) ;
>    }
>    fclose(f);
> 
>    fprintf ( stderr, "fgetc test done\n" ) ;
> <snip>
> 
> In other words, I replaced the original test like:
> 
> while ( InChar = fgetc ( f ) != EOF )
> 
> with:
> 
> InChar = fgetc ( f ) ;
> while ( ! feof ( f ) )
> 
> and doing this for both getc and fgetc loops enables the test to pass,
> along wth all subsequent tests up through 55.

Ok, mmmh, I may have an idea of the problem.

Could you compile the tests2/40_stdio.c with tcc with debug information (tcc -
g -o 40_stdio 40_stdio.c) and verify that the bug is also there in this case 
(./40_stdio does an infinite loop)?

If yes, please attach the binary so that I can look at the generated code 
*and* the output of the test which is in 40_stdio.test.

> There is a failure after
> that, but it looks like this:
> gcc -o libtcc_test libtcc_test.c ../libtcc.a -I. -I/var/log/tinycc -Wall -g
> -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare
> -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI  -DTCC_ARM_VFP -lm -ldl
> ------------ libtest ------------
> ./libtcc_test lib_path=..
> Hello World!
> fib(32) = 2178309
> add(32, 64) = 96
> cp ../include/tcclib.h .
> gcc -o tcctest.gcc tcctest.c -I. -I. -I/var/log/tinycc -w -Wall -g -O2
> -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -DTCC_TARGET_ARM
> -DWITHOUT_LIBTCC -DTCC_ARM_EABI  -DTCC_ARM_VFP -std=gnu99 -O0
> -fno-omit-frame-pointer
> ./tcctest.gcc > test.ref
> /bin/sh: line 1:  7477 Segmentation fault      ./tcctest.gcc > test.ref
> make[1]: *** [test.ref] Error 139
> make[1]: Leaving directory `/var/log/tinycc/tests'
> make: *** [test] Error 2
> 
> which is obviously much farther along (benchmark vs. gcc?)

Indeed. Let's solve the previously mentionned bug and then we'll see for this 
one.

> 
> Hope this helps. I will try the commit you suggest.  Thanks.

Yes it does. Thanks for your efforts.

> 
> Jerry

Thomas

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]