forums.ps2dev.org

Folks;

In updating our stuff from compiled with 2.9xxx to 3.2.2, I've noticed that the function calling conventions are different. This affects any functions taking more than 4 arguments (sprintf anyone?) or lots of the USB functions.

Old compiler stuffed args into $4-$7 then on the stack. The new one stuffs parameters into $4-$9. So, parameter 5 and on are lost in space.

Now, if you compile all the code on both sides of the call, everything is ok. But, if you link against the system libraries (sysclib, usbd etc.), things are not so nice.

I've looked for switches, hints, magic incantations to affect the calling conventions, but to no avail.

Ideas?
tjd

Don't use GCC 3.2.2 for the IOP. It's basically the EE-specific backend, forced into generating R3K code, and it doesn't work as intended.

At this rate it'll never work as intended.

Well, that's depressing... Is there a list of things that "don't work as intended"? At the moment, a fairly large piece of IOP code is running and I want to continue with 3.2.2 unless its hopeless. I can easily bridge around the function call problem by wriiting a bit of assembler, but if there are another 73 large gotchas out there waiting, I might think otherwise.

I think I'll do "yet another patch"... mrbrown's comment just lead me to think that something may be done in no time...

Stay a little bit tuned, please :)

tjd:

There are still quite a few bugs in the latest IOP tools, enough that its basically unusable at the moment. It'll compile and link irx files, but they won't run properly if at all. There's no real list of known bugs yet because the number of people with IOP experience *and* the time to do testing is close to zero, unfortunately...

But there's hope. As long as you can extend some help and give reports like the one you just did, chances are someone will go 'aha!' and dive into it. Pixel here seems to be on the trail of something... that's the way people around here seem to work. :) So any help, information or suggestions you have can be very helpful.

mrbrown wrote:Don't use GCC 3.2.2 for the IOP. It's basically the EE-specific backend, forced into generating R3K code, and it doesn't work as intended.

Well, thats good to know. I am sure this same advice has been buried
in the forums for aeons since the new toolchain was released and I
missed it, but better late than never!

Actually I have been compiling all of the IOP stuff with the new toolchain
and haven't yet run into problems. But then, I haven't done much with
the IOP so far that I have had to compile myself. I am making the simplest
of irx's so probably I am not yet tripping the bugs.

Gorim

Well, I just wrote a small patch there. I couldn't test it right now, since I am too far away from my unix workstation. Blackdroid said he would test it, but, well, the patch is so small, I just wonder how it could fail :-P

Well, this is still something one has to try:

http://www.nobis-crew.org/~pixel/gcc-3. ... only.patch

Since mrbrown said that the current problem with the gcc-3.2.2's patch was the fact that it was a r5900 compiler, I just took the basic IOP/IRX stuff, and put it together into a "lite" version of the patch. So, that should be a plain, flat, r3k compiler.

That patch has to be applied on a vanilla gcc-3.2.2, of course.

The funny thing is that this patch is virtually compatible with the full patch. I mean it is possible to produce two separated incremental patches, one "iop", one "ee", that could be applied on the same gcc's source code. That is, ooPo's script could be turned into something like:


fetching iop-gcc-patch
fetching ee-gcc-patch
fetching gcc-3.2.2 source code
untaring gcc-3.2.2
applying iop-gcc patch
compiling iop-gcc
installing iop-gcc
applying ee-gcc patch
compiling ee-gcc
installing ee-gcc


Well, just have to try, which I can't at all right now ;-)

Cool! I will try it out this weekend!

But I have been wondering, shouldn't it be possible to have only
one gcc, and have it output code based on flags that specify
processor type ? But hey, I am not complaining, two is better
than one I say! At least they both exist! :)

Gorim

That's exactly the actual solution. The current flag is "-miop". And the generated r3000 code is quite not the same as it should be. I actually spotted one big flawn in the stack, and tjd here spotted another $aXX problem. Minus alot of other yet unknown differences.

pixel wrote:Well, I just wrote a small patch there. I couldn't test it right now, since I am too far away from my unix workstation. Blackdroid said he would test it, but, well, the patch is so small, I just wonder how it could fail :-P

Well, this is still something one has to try:

http://www.nobis-crew.org/~pixel/gcc-3. ... only.patch

Since mrbrown said that the current problem with the gcc-3.2.2's patch was the fact that it was a r5900 compiler, I just took the basic IOP/IRX stuff, and put it together into a "lite" version of the patch. So, that should be a plain, flat, r3k compiler.

That patch has to be applied on a vanilla gcc-3.2.2, of course.

Wow, hey! You just duplicated http://forums.ps2dev.org/viewtopic.php?t=106 which has been at the top of the Toolchain Development forum since February 22nd! Congrats!

Was that patch really not included in ooPo's stuff? For shame, ooPo! For shame! ;-P

Looking inside the toolchain-beta.sh script, you can take a look at what's gone into the patches it uses...

# gcc-3.2.2-PS2-20040526.patch:
# pixel 20040214 patch
# mrbrown 20040222 patch
# 'scei' name fix patch

Your 20040222 patch was already applied and absorbed. For shame! :)

While your patch added an IOP target but left EE/IOP/DVP code in the same source, Pixel's patch contains only IOP code. I think the idea is to boil the source down to only what is required for the IOP, and then see if it can be fixed or if it was conflicting with the EE or DVP parts, perhaps merging it back in later if possible.

Since mrbrown said that the current problem with the gcc-3.2.2's patch was the fact that it was a r5900 compiler, I just took the basic IOP/IRX stuff, and put it together into a "lite" version of the patch. So, that should be a plain, flat, r3k compiler.

Right, which is what my patch does. You can apply it to vanilla GCC 3.2.2. It doesn't use anything from the EE port. Except for a few name differences, my patch and pixel's patch are the exact same thing.

I released it to do exactly what you just described - isolate the IOP port to GCC in it's own target. I was just pointing out how funny it was that pixel went and duplicated the patch unnecessarily (in my own odd way :P).

The next real step is to start finding what causes 3.2.2 to generate the wrong calling conventions, my guess is that there were some ELF defaults that changed, or the default ABI changed (from 2.8.1 to 3.2.2 that's not a far stretch). It's probably just a simple ABI change.

You know, you're right. I really should read more carefully. :)

The good news is, it *has* been used in the unstable toolchain build for a while now, its just been merged with pixel's stuff. So...

I'll let you two knock heads and try to figure this out in the meantime.

Err... I completely forgot that. However, it seems your patch is not available anymore, and it seems nobody ever tried it :-P The link is dead I mean, and I just can't think of any report of use of that patch... As we can learn of that is many people are doing work for basically nothing huh... Sorry 'bout that, but it seems people are not really feeling concerned :)

Now, the problem is, as ooPo said, that that patch was "absorbed" into his latests patch. If some parts of that remains somewhere else, that would really be better than that quick dirty hack I made. But ooPo's script NEVER try to build the iop-gcc alone, always using the big merged patch.

Hmm, the link worked yesterday because I wouldn't have posted. I'll get on the webmaster about it. I can e-mail it to you if you want?

Yep, please mail it :)

The process by which the beta toolchain script configures and builds things came about by asking people, especially you two, what would be the best way to do so. If you've been secretly wishing it worked a different way - speak up.

Is building the IOP parts out of the giant merged patches wrong now? Bleh.

I don't have the source in front of me, but if after applying the "IOP only" patch you build with --target=iop I *think* it won't include any of the EE stuff, it should be just a standalone IOP compiler. I don't remember the EE patches being that intrusive. The simple test is to build vanilla GCC + IOP-only, and then full patched GCC, and take a look at the compiler predefines (use -i or whatever the option is to spit out all the predefines).

mrbrown wrote:The simple test is to build vanilla GCC + IOP-only, and then full patched GCC, and take a look at the compiler predefines (use -i or whatever the option is to spit out all the predefines).

That's exactly what I meant actually: having an iop-only patch (which was not existing anymore...) to verify if the EE patch was not intrusing too much. :-P

Actually, the toolchain builds the iop-gcc using the full (ee+iop) patch using --target=iop. And this iop-gcc doesn't work. So, either it's gcc3.2.2 which needs harder tweaks than the old gcc2.8.1, either it's the EE part which is intrusive and breaks the r3000 part, even in --target=iop mode.

Before you guys go too far and take the entire car and engine apart, scattering the parts all over the garage floor, all the time hoping you can build an old DeSoto out of it....

It ain't all that broke is it? I scribbled some assembler to fix my calling conventions problem, fixed some broken prototypes and now I have a boatload of code running on the IOP that was built from gcc-3.2.2.

Can some post a list of the "things we hope to fix"? Seems that there is a "rush to patch" going on here.

(personally, I like the single compiler approach-- seems more elegant. Another compiler build is going to necessitate a bunch of testing)

tjd

They're trying to figure out what is wrong - then they can fix it. :)

Now, if you've got a bunch of code running already it sounds like you're already fixing stuff, or at least working around it. Can you make a general list of what you've done? You're blazing a new bleeding edge here.

As far as I know, the current list of "things we hope to fix" is getting some code to run at all.