Gcc4 And The Sdk

[DJWillis]

Guys,

As no doubt everybody has noticed the GCC with the SDK is somewhat ancient (2.95).

I was looking for a quick show of hands on the platforms people use to develop on (Linux/Windows/MacOS etc.) as if nobody minds I am going to try and do a few straight builds of ARM-LINUX GCC 4 and see if they will cut it (Windows Cygwin 1st).

Getting the SDK working with something like DKArm will require compiling the dev kit for another architecture (ARM-LINUX as opposed to ARM-ELF/THUMB that the GP32, GBA, DS etc. use) and that requires a little more hacking about then I can be arsed with at the moment but I think I can hack over my old GCC build scripts in a few hrs. with some testing. This would be a short term fix until DKArm or some other more integrated build of GCC gets sorted.

Having said all that if any of you have already done this or are playing I won’t waste my time, no point doing anything more then once at the moment .

 

[Squidge]

Also, I'm assuming the provided compiler is only for Linux apps, and that apps run without linux may require a different linkerscript and crt0 (startup code).

 

[DJWillis]

Also, I'm assuming the provided compiler is only for Linux apps, and that apps run without linux may require a different linkerscript and crt0 (startup code).

​

Yep, we would need to know the 'magic' numbers to init the device via a crt0.s and link it all together, not looked at the Linux stuff we have to see if it can be cribbed out but I think it could (or a least have a good starting point), You would also go back to using an ARM-ELF target. DKArm is a multi-target build of GCC and it is deff. where we want to be going. Anything I hack together short term will assume you are running Linux from flash.

 

[Squidge]

I've asked Craig if he can get us the Linux kernel source code - hopefully this will contain everything necessary to initialise the system without having to try and initialise it from reading the datasheets (not very fun - even though I did it on the gp32).

 

[skeezix]

An interesting choice, 2.95; I would've thought they'd standardize on the 3.x line (as the 4.x line is still fairly new and has a few known buglets and optimizaitn guffaws).. but 2.95 was stable for a long long time. Shouldn't be too hard to bump up to a more current build I imagine?

/me will have no PC access for a day or two, and will be all paranoid thinking about this ACCESS buyout of PalmSource for then

jeff

 

[DJWillis]

Good point,

I still use GCC3.* for the most part and have not really moved over to 4. What would you guys like? 3 or 4, I don't mind.

Not got a huge amount of time this weekend so hopfully I will get something together early next week.

 

[woogal]

I find 4 much better at optimisation. 3.x got very picky and would sometimes only work with certain -O settings. 4.x seems happy with all -O settings. Or maybe that was just my complete mess of a dev environment.

 

[Squidge]

I've always thought 3.4 was a nice build. I found 4.0 a bit buggy.

 

[Toris]

I've just compiled version 3.4 of the following files, nothing about them is anything less than standard, but if anyone is interested in testing them (I have not yet got anything setup to compile), then let me know and I'll host them on my webspace.

arm-linux-gnu-addr2line
arm-linux-gnu-c++
arm-linux-gnu-gcc
arm-linux-gnu-objcopy
arm-linux-gnu-readelf
arm-linux-gnu-strip
arm-linux-gnu-ar
arm-linux-gnu-c++filt
arm-linux-gnu-ld
arm-linux-gnu-objdump
arm-linux-gnu-size
arm-linux-gnu-as
arm-linux-gnu-g++
arm-linux-gnu-nm
arm-linux-gnu-ranlib
arm-linux-gnu-strings

Cheers,
Toris.

 

[mr.spiv]

Arr.. I have tried to avoid Linux lowlevel stuff as much as possible past 10 years.. looks like I'm doomed <_<

 

[mr.mirko]

Arr.. I have tried to avoid Linux lowlevel stuff as much as possible past 10 years.. looks like I'm doomed <_<

​

I think, creating a low level SDK, without using Linux, would be the best, and easyest way.
No OS = more Speed.
Direct Hardware access = Full Power !
No trouble installing linux libs and stuff.
just copy your (fxe, whatever) to sd card, select it, with an bootselector, and youre going.

Things need to be done.

A psp like bios.

This means the SDK libs are in the Flash rom. All new compiled Hardware is linked dynamic to this SDK lib. ( To the static addresses in the Flash rom ).

What do you think ?

 

[rlyeh]

i rather like GCC 4.0.1 over any GCC i've tried so far...
give it a chance...

 

[DJWillis]

Toris,

Go for it, may as well give them a try.

 

[Squidge]

Personally, I think we get the compiler set up, and then week until next week. Then the proper SDK should be out, along with the dev units, which should give us valuable info, and we'll know exactly how the hardware works. GPH say it's possible to run apps before linux is booted, but we don't know if this is a file selector, single app, "press b to run sd card instead of linux" or whatever. It could be a translation error for all we know, and there's no such thing.

Also, I fail to see any header files for the mmsp2 registers? I really don't fancy creating these by hand, and would assume Magiceyes already provide such files.

 

[Toris]

Whoops. I'm not sure what went wrong, but when I tested the things they didn't work -- I'm going to give it another go, this time according to the instructions in the chips user manual.

Should be done tomorrow sometime (would have done it sooner, but had work *sigh*)

 

[DJWillis]

Ok, GCC4 is being a pig .

Trying to go for static linked executables as the glibc on the kernel does not support versioned symbols. With a bit of luck that may work.

 

[Squidge]

and before anyone try's to create a 2.95/3.x hybrid, it doesn't seem to work

collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
make: *** [squidge] Error 1

 

[mr.spiv]

and before anyone try's to create a 2.95/3.x hybrid, it doesn't seem to work

collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
/usr/local/arm-dev/arm-linux/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
make: *** [squidge] Error 1

​

Yep.. remembering things from past it's not possible to mix libs etc across gcc 2.x and 3.x. I had this problem earlier with some of my Linux apps years back. They changed something fundamental there.. related to libs or something.

 

[DJWillis]

I got a fully staticly linked GCC4 ARM-LINUX going and Squidge is using it.

I then stuffed the image on my GP2X so I have not played much with it but if anybody wants an ARM-LINUX based compiler that builds big static linked executables (working on a compressor) then I have some hacky build scripts and some pre-made tool-chains so give me a poke .

 

[Squidge]

Yup, work fine on some stuff (UAE), but not on others (Quake falls over regardless of optimization level, but works fine with -O3 on 2.95), but I'm sure that'll be the same for the GP32 version of GCC4 too, or you need to do something special that only Woogal knows about

Afterall, a big well done to DJWillis

Just a shame he fubar'd his linux kernel before managing to try it himself. He's probably just doing some hardware hacking now instead