Gamba forms fail on Debian ARM

[GoogleCodeExporter]

See:

http://www.raspberrypi.org/forum/projects-and-collaboration-general/gambas/page-
3/#p68904

Original issue reported on code.google.com by tvijlbr...@gmail.com on 24 Apr 2012 at 5:12

[GoogleCodeExporter]

Alas I don't have any ARM architecture where I could debug Gambas.

You can help by:
1) Compiling Gambas from sources on the Raspberry.
2) Providing gdb stacktraces.
3) Running program with valgrind and sending the output.

And I strongly suggest using Gambas 3 and not Gambas 2 anymore.

By the way, someone wrote a big program with Gambas 2 on an embedded ARM 
architecture, but with no GUI at all. So there is some hope!

Original comment by benoit.m...@gmail.com on 24 Apr 2012 at 12:23

• Changed state: NeedsInfo
• Added labels: Version-2.24.0
• Removed labels: Version

[GoogleCodeExporter]

Ok, I'll look into it.

I have a weird gdb issue however:

user@Nokia-N800-43-7:~/tmp$ gbr2 hello.gambas
Hello
user@Nokia-N800-43-7:~/tmp$ gdb gbr2
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/gbr2...(no debugging symbols found)...done.
(gdb) run hello.gambas
Starting program: /usr/bin/gbr2 hello.gambas
[Thread debugging using libthread_db enabled]
ERROR: #45: File or directory does not exist

Program exited with code 01.

So, i cannot debug gbr2 in the normal way. I get an error
message from gbr2 which does not occur when invoked from the commandline
outside gdb???

Any hints? This works ok on i386.

Note that you can run arm programs with qemu without buying hardware:

http://www.cnx-software.com/2011/10/18/raspberry-pi-emulator-in-ubuntu-with-qemu
/

Original comment by tvijlbr...@gmail.com on 24 Apr 2012 at 4:15

[GoogleCodeExporter]

I will try to do the QEMU stuff, but I don't have a lot of time.

gbr2 is not an executable, it is a symbolic link to gbx2.

To do the debugging, you need to go the the project source directory and run 
the interpreter there.

$ cd <project/path>
$ gdb gbx2

Look at the "reporting a problem" on the website.

Original comment by benoit.m...@gmail.com on 24 Apr 2012 at 4:32

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I'm getting somewhere, the call stack fails at an infinite call to pow():

(gdb) where^M
#0  *pow (x=10, y=-1) at gbx_math.c:250^M
#1  0x0002a504 in *pow (x=10, y=-1) at gbx_math.c:250^M
#2  0x0002a504 in *pow (x=10, y=-1) at gbx_math.c:250^M
#3  0x0002a504 in *pow (x=10, y=-1) at gbx_math.c:250^M
#4  0x0002a504 in *pow (x=10, y=-1) at gbx_math.c:250^M
#5  0x00036ad0 in read_float (option=<value optimized out>, ^M
    str=<value optimized out>, len=<value optimized out>, ^M
    value=<value optimized out>) at gbx_number.c:290^M
#6  NUMBER_from_string (option=<value optimized out>, ^M
    str=<value optimized out>, len=<value optimized out>, ^M
    value=<value optimized out>) at gbx_number.c:387^M
#7  0x0001dc58 in CLASS_load_without_init (class=<value optimized out>)^M
    at gbx_class_load.c:1047^M
#8  0x00032938 in load_exported_class (arch=<value optimized out>)^M
    at gbx_archive.c:138^M
#9  0x000438dc in COMPONENT_load (comp=0x6ba14) at gbx_component.c:266^M
#10 0x00043d38 in COMPONENT_load_all () at gbx_component.c:127^M
#11 0x00023cb0 in PROJECT_load () at gbx_project.c:465^M
#12 0x00035794 in init (file=0x50651 ".") at gbx.c:112^M
#13 0x00035e10 in main (argc=1, argv=<value optimized out>) at gbx.c:336^

Note that the debugger shows your own version of powl() (gbx_math.c:250) with 
long doubles although read_float calls pow() and not powl() !!!

Also config.h seems to lie about powl and modfl because when I change the 
definition
the compiler complains about redefinition, so they are probably gcc builtin.

Another issue is that on amd64 long floats are 16 bytes, on i386 they are 12 
bytes and on arm they are 8 bytes. Somehow the problem seams related to the 
usage of long double.

When I remove the definition of eg powl in your gbx_math.c than modules fail to 
load so I assume they are really used under the hood?

I'll test some more.

I did find a bug in gbx_math.c:

your definition of

#ifndef HAVE_MODFL
long double modfl(long double x, long double *iptr)
{
        double val;
        return modf((double)x, &val);
        *iptr = val;
}
#endif

You assign *iptr after the return!
I think it should be:

#ifndef HAVE_MODFL
long double modfl(long double x, long double *iptr)
{
        double val;
        double retval= modf((double)x, &val);
        *iptr = val;
        return retval;
}
#endif

Original comment by tvijlbr...@gmail.com on 25 Apr 2012 at 7:20

[GoogleCodeExporter]

Eureka:

user@Nokia-N800-43-7:/media/data/user/gamba/gambas3-3.1.1$ gcc testpow.c
user@Nokia-N800-43-7:/media/data/user/gamba/gambas3-3.1.1$ ./a.out 
8
segmentation fault
user@Nokia-N800-43-7:/media/data/user/gamba/gambas3-3.1.1$ cat testpow.c 
#include <math.h>
#include <stdio.h>

long double powl(long double x, long double y)
{
  return pow(x, y);
}

int main()
{
  long double i= -5;
  printf("%d\n", sizeof(i));
  for (; i<=5; i++)
  printf("%g\n", (double)10*pow(10,i));
}

====

So defining a version of powl causes the segfault!

What happens under the hood is that the symbol powl is replaced by pow
by the compiler. So the powl(long double,long double) is mapped to 
pow(double,double). Your powl() definition turns into

double pow(double x, double y)
{
  return pow(x, y);
}

A recursive funtion which eats up the stack until it segfaults.

I'm now recompiling with a patched config.h:

/* Define if you have modfl function. */
/* #undef HAVE_MODFL */
#define HAVE_MODFL 1

/* Define if you have powl function. */
/* #undef HAVE_POWL */
#define HAVE_POWL 1

I'm not sure about the (best) fix. Suggestions?

Original comment by tvijlbr...@gmail.com on 25 Apr 2012 at 7:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

gamba3 runs after a recompile and install.

I restored the config.h and I'm now doing a recompile with the critical 
gbx_math.c definitions changed to:

...

#ifndef __arm__
#ifndef HAVE_POWL
long double powl(long double x, long double y)
{
        return pow((double) x, (double) y);
}
#endif

#ifndef HAVE_MODFL
long double modfl(long double x, long double *iptr)
{
        double val;
        double retval= modf((double)x, &val);
        *iptr = val;
        return retval;
}
#endif
#endif

...

Original comment by tvijlbr...@gmail.com on 26 Apr 2012 at 4:17

[GoogleCodeExporter]

I'm currently trying to compile Gambas 3 with QEMU, but it takes hours and 
hours.

I have removed all "long double" functions, as they are not used anymore in 
Gambas 3. So there is no need anymore to patch 'gbx_math.h' and 'gbx_math.c'.

I had one some strange warning during the compilation of the interpreter, but I 
don't know why yet. I don't have it with gcc 4.6 on x86.

Original comment by benoit.m...@gmail.com on 26 Apr 2012 at 2:02

[GoogleCodeExporter]

I finally succeeded in running the Gambas 3 IDE on a Raspberry Pi QEMU 
emulator. 

So I don't think I will fix Gambas 2.

Now something that could be interesting to develop is the availability to run 
the IDE on a x86 and debug a program running on a Raspberry Pi...

Original comment by benoit.m...@gmail.com on 26 Apr 2012 at 4:04

• Changed state: WontFix

[GoogleCodeExporter]

Yes,  compiling takes a while.

Ok,  removing the long double functions will solve the ARM issue in an
elegant and efficient way.

I consider the issue closed now. Gamba3 works ok on my ARM platform.

Thanks for your efforts!
Op 26 apr. 2012 16:02 schreef <gambas@googlecode.com> het volgende:

Original comment by tvijlbr...@gmail.com on 26 Apr 2012 at 4:54