binutils-2.14's patch

[pixel]

Hello,

I've end up creating a Work In Progress patch against binutils-2.14 in order to regroup and merge all the previous EE, IOP and DVP patches.

The patch is here:

http://www.nobis-crew.org/~pixel/binuti ... ch.diff.gz

You have to apply it of course on a vanilla binutils-2.14 source tree. Then, it will behave the same way of all the older binutils. You can configure it with --target=ee, iop, dvp, and now, ps2. I added "ps2" as beeing an alias for "ee", since the generated binutils will be fully backward compatible with the iop-binutils too. It means that ee-as/ee-ld (or ps2-as/ps2-ld if you use the new target I created) should behave exactly the same as iop-as/iop-ld, if you specify the same command-line options, that is -march=r3000 and -m mipsirx (yes, "-m mipsirx" was not mandatory before)

Ho, don't forget: -mCPU won't work anymore... use -march instead.

Now, for me, it's still work in progress. It means this was tested a bit, but needs more intensive inner checks. So, if you are willing to help, please try to compile your projects using it, test if it works, and post back here :). Also, I'm interested to know if it compiles/works under cygwin. ;-)

[Oobles]

Great work..

Which version of GCC should go with this? Use the same versions as before with their associated patches?

[pixel]

Thanks ^^;

Yep, exactly, for now, the older gcc should still be used. I'm now looking at gcc's sources in order to produce a patch for it.

[OptiRoc]

Fresh! Will test these under Cygwin during the next couple of days.

On a related note, what is "the situation" with SCE-developed binutils/gcc patches? For example, the support for VU0 in their EE toolchain is rather nifty, and as far as I know we don't have it in our compilers (correct me right away if I'm wrong). Any improvements made to the GNU tools should remain free, shouldn't they -- or can SCE circumvent this in some way?

[pixel]

SCE actually can.... by providing "precompilers". That's actually what they do. Although I do not exactly know the differences between the dvp-as provided here, and the ee-dvp-as provided by SCE, I know they provide some additionnal precompilers, like "vcl", which will generate vsm sources.

[OptiRoc]

Yes, but there are also modifications done to GCC that adds inline support for VU0-code (referred to as "Dylan's VU0 support patches"). These are mentioned in the following project at PS2linux:
http://playstation2-linux.com/project/d ... .php/5_125

Some details here:
http://playstation2-linux.com/project/d ... r_common.h

Now, I'm not a GCC whiz (this is where you come in!), nor very familiar with the GPL terms, so... What does the GPL say about these improvements to the actual GCC compiler?

[pixel]

I am not a gcc wizard too ^^; I just tend to know how the whole thing ties up and works, so I can tweak it a bit. I play with binutils/gcc since a long time now, creating weired cross compilers ^^ But it's a quite easy task actually...


The GPL say more or less (well, that's the basic idea... don't ask me for the inner details) that one has to give out the modifications done to a GPLed package. But I'm actually unaware of the nature of the modifications done by SCE to the direct gnu tools. Moreover, I think that part of the patches I have here are originated from sony themself (or from SN systems). I have to admit I'm really confused ^^; But all the patches I saw more or less looked the same.

But if they have, say, a gcc/binutils toolchain that produce plain elf files, which you have to convert using a Sony's ELF->IRX converter, then, they do not have to give out this tool.


Well, if I understand correctly what I quickly looked at, the "ps2stuff" package includes some inline ASM statements, but which are not direct DVP code. Or is it ? That would mean that this kind of code should compile with the "current" gcc, or with the patched one, with the patch he gives:

http://playstation2-linux.com/project/d ... tuff.patch
http://playstation2-linux.com/project/d ... tuff.patch


Anyway, the main idea is to stick with newer versions of binutils/gcc. That's why I tried to sort out all the binutils's patches (actually, there were 2 main patches, the IOP and the EE ones, and one 'ugly' package containing binutils and gcc with ee and dvp patches, that I managed to take the DVP part out.)

So, for me, it's even a miracle this actually woks ^^; I don't understand *all* the patches I put together into the pool. A few things remains unknown for me. Hopefully, they are more related to the disassembler part than anything else. "Monkey work" huh :-)

Afterward, the same will have to be done with gcc. That is, grabbing all the patches around, and try to summarize them into a newer gcc's version. The only problem is that gcc's code has heavely changed since then. When I thought that binutils would be the more difficult issue to deal with, it appears that it maybe will be gcc. Messing up with a compiler toolchain is not so easy :-P

So, I'll try to grab every patches for gcc, understand them, and try to merge them together. That's not gonna be an easy task though :) I'll look at this ps2stuff more intensively later. Thanks for the link :)

[OptiRoc]

I believe the first patches originated from Cygnus (Red Hat), who wrote them for SN Systems' original PS2 SDK's in 1999. It would seem that Dylan Cuthbert's VU0 patches also filtered down to the PS2dev community, according to this:

http://ps2dev.sourceforge.net/hypermail-past/0009.html

So I reckon the VU0 macro-mode functionality may very well be in the current patches (can't try it out for the moment). Someone care to set the record straight? Blackdroid?

[MrHTFord]

Hi Pixel,

Good to hear someone's working on toolchain issues.

What are your plans for gcc? When you say gcc's moved on a lot, are you refering to 3.2.2 against 3.4? The mips side of gcc was completely re-written for 3.4. It's much cleaner than before, and integrating the patch would require understanding the whole patch.

Personally, I'd like to see the bugs ironed out of the current patchsets before we port them to later versions. I've got a zip file with a test case of the .bss align bug.

If I can be of any help, let me know.

[mrbrown]

Thanks ^^;

Yep, exactly, for now, the older gcc should still be used. I'm now looking at gcc's sources in order to produce a patch for it.

GCC 3.2.2 doesn't work with your patches?

[mrbrown]

Hi Pixel,

Good to hear someone's working on toolchain issues.

What are your plans for gcc? When you say gcc's moved on a lot, are you refering to 3.2.2 against 3.4? The mips side of gcc was completely re-written for 3.4. It's much cleaner than before, and integrating the patch would require understanding the whole patch.

Personally, I'd like to see the bugs ironed out of the current patchsets before we port them to later versions. I've got a zip file with a test case of the .bss align bug.

If I can be of any help, let me know.

Are you sure the .bss bug is specific to the EE toolchain and not GCC 3.2.2? Do you get the same bug in the 2.9EE toolchain?

[mrbrown]

Fresh! Will test these under Cygwin during the next couple of days.

On a related note, what is "the situation" with SCE-developed binutils/gcc patches? For example, the support for VU0 in their EE toolchain is rather nifty, and as far as I know we don't have it in our compilers (correct me right away if I'm wrong). Any improvements made to the GNU tools should remain free, shouldn't they -- or can SCE circumvent this in some way?

There is no "situation" - licensed developers that have legal access to Sony's GCC are free to distribute those changes under the GPL. No one has done it yet.

[pixel]

GCC 3.2.2 doesn't work with your patches?

It's not the "3.2.2" problem. It's the 2.8.1 one :-) The IOP-gcc. I mean, it's soooooooo old... I wanna do something for it. So, I have two choices here. Either I small-patch gcc-3.2.2 in order to make it support the iop-binutils (reaaaaally not a problem at all I think), either we put everything (iop and ee) into a single 3.4 patch.

The more I look at it, the more I think there will be a small-form factor patch against the current ee-gcc-3.2.2 in order to support the iop target as well ^^;

[pixel]

There is no "situation" - licensed developers that have legal access to Sony's GCC are free to distribute those changes under the GPL. No one has done it yet.

Actually, I asked some guys at the FSF in order to get clarification about this. They answered that Sony has two choices:

-) Either they provide the patch for everybody from their website, or release it at demand for any external people asking for the changes
-) Either they provide the patch to anyone getting their official devkit (and thus, do not need to do any public release).

They as well told me to try to get the information if they provide the patch or not with the devkit. If not, we have the right to ask for it publically, and we should CC the FSF when doing this demand.

That goes for SN system as well.

--EDIT--

After chatting with mrbown on IRC, it appears they fall in the second category I said, meaning they provide the patch privately to all the official developpers, and thus, do not have to do any public release. So, they are in all their rights, and it means we still will have to build up our toolchains by ourselves :-)

[OptiRoc]

There is no "situation" - licensed developers that have legal access to Sony's GCC are free to distribute those changes under the GPL. No one has done it yet.

So, in effect, any SCEx-developed (or by any other party) patch for the GNU tools are okay to spread -- provided you have the means to do so (ie you're a developer with access to them). I no longer belong to a licensed company (did in 1999), but.. the question is still of great interest.

[Guest]

Are you sure the .bss bug is specific to the EE toolchain and not GCC 3.2.2? Do you get the same bug in the 2.9EE toolchain?

Pretty sure. 90% maybe. I'll look into it today. Also, just discovered we're missing an opcode from mips-opc.c, Pixel and ooPo, you'll want to add this to your patchsets:-

Code: Select all

{"madda.s", "S,T",      0x4600001e, 0xffe007ff, RD_S|RD_T|FP_S,		T5	},

Cheers,

MrHTFord.