GP2X Native Arm Toolchain On Gp2x


crusty

Still Fresh
Joined
Jan 2, 2006
Messages
64
Location
Barbados, West Indies
Website
Visit site
Has anyone tried to run gcc on the GP2X directly?

The serial port access (either GPIO or USB gadget) provides
terminal access and 200 mhz cpu speed is more than fast
enough for compiling.

Just thought I would ask.
 
It should work but I see no reason to. It would take too long to compile large programs.
 
It might be half workable with a boot hack to make linux use all 64MB of RAM...
 
I'd rather like to see integrated assembler/debugger with an editor. It should work fast and would allow much faster developing and experimenting with GP2x hardware.
 
Radek posted on Mar 9 2006 at 09:00 AM said:
I'd rather like to see integrated assembler/debugger with an editor. It should work fast and would allow much faster developing and experimenting with GP2x hardware.

YES PLEASE!

I'm playing around with something which may become a native toolchain of sorts. It's Forth not c so it may not be useful for most people, however it will include an assembler. Don't expect a release anytime soon, I'm learning as I go and doing it all for my own amusement :)
 
Last edited by a moderator:
i've called for an ARM-native port of gcc and all the syslibs (and the kernelpack, and /bins') that can be compiled on the gp2x, by the gp2x (i.e. making the gp2x entirely self-hosting) since before the GP2X was released ...

it'll happen. for sure! ;)

/glances at his 60gig USB datatank ..
 
This would also be very useful once there is a good GP2X emulator (if it can run > 266Mhz). No wierd cross compiling, and the speed of a multi GHz proccesser should make development/testing a bit easier!
This would also solve my Python distutils woes...
 
There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler, so running it through a GP2X emulator would be pretty silly.

What I want to see on the GP2X is a memory debugging util ala Valgrind... I've got a bug in a program where it segfaults when I free an SDL_RWops on
GP2X but x86 valgrind says there isn't any problem (it runs fine on PC btw)
 
Mudi posted on Mar 9 2006 at 11:45 AM said:
There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler...
Except the environment/tools/libs available at compile time. Distutils are very sensitive to the environment they (and their Python) are run in. Also They run a bunch of tests on the resulting binaries... which all fail when you cross-compile (or so I've read my google research, I haven't even gotten them looking in the right place yet :( ).

I can see how there would be less advantage for everyone else though, just cross compiling then testing in an emulator would be quicker and just as easy.
 
Last edited by a moderator:
Mudi posted on Mar 9 2006 at 08:45 PM said:
What I want to see on the GP2X is a memory debugging util ala Valgrind... I've

It's not valgrind, but will at least help when you're accessing your heap (malloc'd) memory wrong.
Electric Fence helps you detect two common programming bugs:
software that overruns the boundaries of a malloc() memory
allocation, and software that touches a memory allocation that has been
released by free(). Unlike other malloc() debuggers, Electric Fence will
detect read accesses as well as writes, and it will pinpoint the exact instruction that
causes an error.

You might have freed the memory before, just not realise it. Link with -efence:

http://luteijn.xs4all.nl/html/gp2x/efence/....13/libefence.a
 
Last edited by a moderator:
Kitsu posted on Mar 10 2006 at 12:42 AM said:
Mudi posted on Mar 9 2006 at 11:45 AM said:
There shouldn't be any difference in the executables produced by the cross-compiler and the native-compiler...
Except the environment/tools/libs available at compile time. Distutils are very sensitive to the environment they (and their Python) are run in. Also They run a bunch of tests on the resulting binaries... which all fail when you cross-compile (or so I've read my google research, I haven't even gotten them looking in the right place yet :( ).

I can see how there would be less advantage for everyone else though, just cross compiling then testing in an emulator would be quicker and just as easy.
I've been using qemu-arm to run some programs while compiling eg basiliskii needs to generate cpu code from a program halfway through compiling. i suppose it might be possible to build the whole toolchain using oopo's script in qemu-arm. it would be possible to just copy that into the gp2x.
Scratchbox also uses qemu-arm i tthink
l
 
Last edited by a moderator:
Sorry for bumping an oldish topic, but here is a native GCC for the Zaurus. If anybody still needs a C compiler on the gp2x, this should do the job, right?
 
Back
Top