GCC 8.2.0

hammy

Member
Jun 1, 2019
86
46
18
UK
Some further progress notes (going is slow for the moment, holidays + other commitments):

  • All official GCC releases back to 4.8.0 exhibit the problem with base stack frames (broken C++ exceptions, debugging isn't reliable)
  • I've verified that the GIT version before IRIX support was removed is OK
  • I've verified that the GIT version after IRIX support was removed (and re-patched with our approach) is OK

Interestingly, patching support back in doesn't require forcing DWARF to version 2 and strictness in iris6.h - and in fact doing that that breaks base stack frames.

One other thing of interest - I've seen internal compiler errors when attempting to build some of these old GCC versions using our "semi-working GCC8" - so for the moment I'm bootstrapping these test versions using 4.7.4.

I'm currently building some tooling to automate as much of the "patch back irix support" - so now the job is to start bisecting between the version after IRIX support removal - and 4.8.0.

D
 

hammy

Member
Jun 1, 2019
86
46
18
UK
Good news - after 15 bisection jumps I present to you the first breaking commit:


Bad news - is a dooozy of a commit with lots of changes in there. And somewhere in there, is a breaking change.
 
  • Like
Reactions: Elf

hammy

Member
Jun 1, 2019
86
46
18
UK
Far as I can tell, this patch gets exceptions + debugging working for me on top of a release 8.2.0 tarball.

Note: This isn't the same "root" (although it heavily borrows) from the sgug dev git tree - so it doesn't have cross compilation support. That exercise is left for dear reader .-)


Same pre-reqs and cycle of builds as per the other gcc versions.

I'll start a clean build of everything in "didbs" and make a tarball available over the next week with prebuilt versions for mips4/n32 so that people can kick the tyres without having to go through the pain of re-producing the build.
 
Last edited:

Geoman

Member
Dec 28, 2019
34
12
8
Germany
phantastic work you're doing there! a friend of mine is trying to build gcc, but the linker doesn't work for 64 bit programs. Do you have found a solution for this in your build?
 

hammy

Member
Jun 1, 2019
86
46
18
UK
phantastic work you're doing there! a friend of mine is trying to build gcc, but the linker doesn't work for 64 bit programs. Do you have found a solution for this in your build?
Hey Geoman,

I'm afraid both the gcc and binutils builds have only had work put in on n32/32bit. To get 64 bit working, gcc must be built + fixed "multilib" and binutils should be checked + fixed to get 64 bit builds working.

Patches are welcome .-)
 

Geoman

Member
Dec 28, 2019
34
12
8
Germany
Hey Geoman,

I'm afraid both the gcc and binutils builds have only had work put in on n32/32bit. To get 64 bit working, gcc must be built + fixed "multilib" and binutils should be checked + fixed to get 64 bit builds working.

Patches are welcome .-)
a good friend of mine (aka Icehwk) is currently working on it. We'll keep you posted.
 
  • Like
Reactions: Elf

Geoman

Member
Dec 28, 2019
34
12
8
Germany
we're failed several times to get multilib running. so currently no 64bit gcc. for now we try to compile the latest 32 bit firefox with what we have now.
 

Geoman

Member
Dec 28, 2019
34
12
8
Germany
the amount of pathcing that has to be done is insane, and he does not much of documentation. If there's success, we're conservating the whole build environment. Here is an example of the process:

bash-5.0$ python
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python 2.7.16 (default, Jan 2 2020, 19:03:12)
[GCC 9.2.0 20190812 (sgugver-0.1.9-mips4)] on irix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getpid
<built-in function getpid>
>>> exit()
______
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... yes
______

[20:39, 2.1.2020] icehwk: Er merkt das es da ist (=the computer sees it)
[20:39, 2.1.2020] icehwk: Aber dann nachher motzt er, das er nicht weiss, wo es ist (but then he complains, that he doesn't know, where it is)
______
[20:41, 2.1.2020] icehwk: ich such raus, wo das definiert ist und zwing den dann dazu den header zu includen (so I'm looking for places, in which it is defined, and I force it to use the header)
[20:41, 2.1.2020] icehwk: was besseres kann ich momentan nicht machen (no better way of doing it)
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
If it's of any help, I could make a diff of what I've done so far.

I've gotten somewhere rather far with it, to a point where I got to figure out linker flags so that linker does not run out of 32-bit address space (--no-keep-memory and --reduce-memory-overheads). My last recollection from last summer are of it wanting to link against some OS X audio library because some if-then-construct somewhere does not recognize IRIX and also the hardships of building a working Skia library + there being a flag telling the build not to use Skia that does not actually do what it says.
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
Oh, I thought you were talking about Firefox. My bad. Did gcc9 build with multilib? I don't know what's in there right now, but IRIX multilib used to mean o32, n32 and n64. You probably don't want o32 and I remember that being problematic enough for me to stop trying and just going with n32.
 

Eschaton

New member
Nov 6, 2019
6
1
3
If you can figure out what the binutils/ld issue is, I’d appreciate some prose (no code) describing it in detail so I can try to apply similar fixes to LLVM/lld. I had to back-burner the LLVM/lld/clang work because of some unfortunate family/life events a couple months ago; it’ll be fun to pick back up again.

(I also have a good relationship with lots of folks who work in those areas of LLVM so if I can get a sufficient description of the issues with binaries generated by modern binutils, getting help fixing the equivalent issues in lld shouldn’t be difficult.)
 

onre

SYS 64738
Feb 8, 2019
121
56
28
Toijala, Finland
The 9.2.0 by @hammy is the one that works best now, 8.2.0 and my work on binutils is basically abandoned now as we have a better alternative there. You may want to look there for the fixes.
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu