Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Thu Apr 17, 2014 7:09 pm

All times are UTC - 8 hours


Forum rules


Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.



Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: A modern GCC on IRIX 4
Unread postPosted: Wed Nov 07, 2012 5:27 pm 
Offline
User avatar

Joined: Fri Oct 24, 2003 2:24 pm
Posts: 41
Location: Oberlin, OH
Has anyone looked into getting a modern version of GCC to run on IRIX 4? I have an Indigo running 4.0.5F and have toyed with builds on and off for a while, with little promise of success until recently.

The most recent version of GCC that will build successfully on IRIX 4 without modifications is GCC 3.0.4. 3.1 and 3.2 have problems with gcc/config/mips/mips.md, and after that the GCC folks dropped compatibility with older versions of IRIX. However I recently succeeded, with some source modifications, in building cross-compilers of 3.4.6 and 4.1.2 (x64 NetBSD host). Unfortunately I can't get 3.4.6 to build natively. The first major problem is a command line that exceeds NCARGS (only 10248!) but even after circumventing that problem I get internal GCC errors before the end of the build. I have not yet invested the time to try building 4.1.2 natively but will soon. And I thought gcc builds on my Octane2 were slow!

If anyone else is working on this or has any advice, I'd love to hear it. I bet this work could be leveraged to IRIX 3 too, they are very similar from GCC's perspective.


Top
 Profile  
 
Unread postPosted: Thu Nov 08, 2012 12:13 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3769
Location: Wijchen, The Netherlands
I've been building GCC on IRIX 3 a couple of years ago and the biggest problem is the pre-ANSI C library.

I put together a compatibility library to cover some of that and with that I could build GCC 3.0.4 on IRIX 3.3.

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Thu Nov 08, 2012 9:47 am 
Offline

Joined: Thu Jun 02, 2011 2:13 pm
Posts: 90
Location: Germany
I suppose you mean a R4k Indigo, or are you actually building 3.x gccs on an R3k? :)
hbent wrote:
And I thought gcc builds on my Octane2 were slow!

I'm currently bootstrapping some 3.x gccs on a SPARCclassic :roll:

But nice project. I once build 3.4.6 for 5.3 (didn't go further because I was too lazy building gcc's dependencies), but didn't go down to 4 with gcc on my Indigo², yet.


Top
 Profile  
 
Unread postPosted: Thu Nov 08, 2012 9:58 am 
Offline
User avatar

Joined: Fri Oct 24, 2003 2:24 pm
Posts: 41
Location: Oberlin, OH
I did mean an R4k Indigo, doing this on an R3k would be like watching paint dry. Though I did build 3.3.6 once on a Mac IIci running A/UX, as I recall it took well over 24 hours, probably very similar to working on a SPARCclassic.

My main motivation is to get to a version of GCC that knows about the R4000 errata. I'm hoping it will fix the coredumps I sometimes get when compiling software with -mips2.


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 12:15 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3769
Location: Wijchen, The Netherlands
Somewhere in the early GCC 3.x series it stopped working on R3K CPUs. I suspect someone used R4K instructions in the crtbegin/crtend assembly code.
hbent wrote:
I did mean an R4k Indigo, doing this on an R3k would be like watching paint dry.

That, or you need something with *a lot* of R3000 CPU's, like a PowerSeries 'Predator' rack :D

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 4:02 am 
Offline
User avatar

Joined: Fri Oct 09, 2009 1:44 am
Posts: 226
Location: Orgerus (France)
jan-jaap wrote:
Somewhere in the early GCC 3.x series it stopped working on R3K CPUs. I suspect someone used R4K instructions in the crtbegin/crtend assembly code.

Aren't the various crt* files provided by the operating system? gcc does not provide such files.

_________________
:Indigo:R4000 :Indigo2:R4400 :Indigo2IMP:R4400 :Indigo2:R8000 :Indigo2IMP:R10000 :Indy:R4000PC :Indy:R4000SC :Indy:R4600 :Indy:R5000SC :O2:R5000 :O2:RM7000 :Octane:2xR10000 :Octane:R12000 :O200:2xR12000 :O200: - :O200:2x2xR10000 :Fuel:R16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI, Motorola, NeXT, SGI, Solbourne, Sun...


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 4:58 am 
Offline
User avatar

Joined: Thu Jun 17, 2004 10:35 am
Posts: 3769
Location: Wijchen, The Netherlands
miod wrote:
Aren't the various crt* files provided by the operating system? gcc does not provide such files.

GCC on IRIX provides crtbegin.o and crtend.o to deal with constructor/destructor stuff.

Edit: crtbegin/end are built from C code, but the mips specific code does contain two asm files. Or maybe the GCC code generator got borked, who knows.

_________________
Now this is a deep dark secret, so everybody keep it quiet :)
It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi

Currently in commercial service: Image :Onyx2:(2x) :O3x02L:
In the museum: almost every MIPS/IRIX system.
Wanted: GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 1:35 pm 
Offline
User avatar

Joined: Fri Oct 09, 2009 1:44 am
Posts: 226
Location: Orgerus (France)
jan-jaap wrote:
miod wrote:
Aren't the various crt* files provided by the operating system? gcc does not provide such files.

GCC on IRIX provides crtbegin.o and crtend.o to deal with constructor/destructor stuff.

Ah, right, the joys of the collect2-as-an-ld-wrapper platforms.

jan-jaap wrote:
Edit: crtbegin/end are built from C code, but the mips specific code does contain two asm files. Or maybe the GCC code generator got borked, who knows.

Well, the two .S files seem mips1-compatible to me. What may be wrong, OTOH, are the stack adjustments. The mips default frame size in gcc-produced code has changed several times over gcc development, and since almost noone tests gcc on IRIX < 5 those days, it is very likely that a stack frame size change has been applied everywhere but in gcc/config/mips/crt[in].asm...

_________________
:Indigo:R4000 :Indigo2:R4400 :Indigo2IMP:R4400 :Indigo2:R8000 :Indigo2IMP:R10000 :Indy:R4000PC :Indy:R4000SC :Indy:R4600 :Indy:R5000SC :O2:R5000 :O2:RM7000 :Octane:2xR10000 :Octane:R12000 :O200:2xR12000 :O200: - :O200:2x2xR10000 :Fuel:R16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI, Motorola, NeXT, SGI, Solbourne, Sun...


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 1:49 pm 
Offline
User avatar

Joined: Fri Oct 24, 2003 2:24 pm
Posts: 41
Location: Oberlin, OH
miod wrote:
Well, the two .S files seem mips1-compatible to me. What may be wrong, OTOH, are the stack adjustments. The mips default frame size in gcc-produced code has changed several times over gcc development, and since almost noone tests gcc on IRIX < 5 those days, it is very likely that a stack frame size change has been applied everywhere but in gcc/config/mips/crt[in].asm...


Frames are definitely my problem at the moment. The cross-compiler generates them correctly:
Code:
         .frame  $fp,24,$31              # vars= 0, regs= 2/0, args= 16, gp= 0


but the native compiler is totally wacked:

Code:
        .frame  $fp,12698368,(null)             # vars= 24, regs= 269896524/0, args= 0, gp= 0


I was working on the assumption that it was a problem with the compiler I was using to build gcc, and have switched to a different one for the run I'm doing now. Is there something else I should look into?


Top
 Profile  
 
Unread postPosted: Fri Nov 09, 2012 2:39 pm 
Offline
User avatar

Joined: Fri Oct 09, 2009 1:44 am
Posts: 226
Location: Orgerus (France)
hbent wrote:
Frames are definitely my problem at the moment. The cross-compiler generates them correctly:
Code:
         .frame  $fp,24,$31              # vars= 0, regs= 2/0, args= 16, gp= 0

but the native compiler is totally wacked:
Code:
        .frame  $fp,12698368,(null)             # vars= 24, regs= 269896524/0, args= 0, gp= 0

I was working on the assumption that it was a problem with the compiler I was using to build gcc, and have switched to a different one for the run I'm doing now. Is there something else I should look into?

This smells like variadic functions (in that case, fprintf), are not working correctly. Are you sure your native compiler is built as an o32 binary (I'm not 100% sure anymore, but I doubt I am wrong assuming IRIX 4 uses the o32 ABI). Furthermore, if you're on an R4000 system, are you sure the native compiler isn't trying to output 64 bit code behind your back, or isn't built to expect an n64 world? An n32 vs o32 problem seems more likely so far, though.

_________________
:Indigo:R4000 :Indigo2:R4400 :Indigo2IMP:R4400 :Indigo2:R8000 :Indigo2IMP:R10000 :Indy:R4000PC :Indy:R4000SC :Indy:R4600 :Indy:R5000SC :O2:R5000 :O2:RM7000 :Octane:2xR10000 :Octane:R12000 :O200:2xR12000 :O200: - :O200:2x2xR10000 :Fuel:R16000 :A350:
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI, Motorola, NeXT, SGI, Solbourne, Sun...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group