GCC 8.2.0
- Thread starter onre
- Start date
Some further progress notes (going is slow for the moment, holidays + other commitments):
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
- 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
Good news - after 15 bisection jumps I present to you the first breaking commit:
github.com
Bad news - is a dooozy of a commit with lots of changes in there. And somewhere in there, is a breaking change.
Remove unnecessary VEC function overloads. · gcc-mirror/gcc@e82e4eb
Several VEC member functions that accept an element 'T' used to have two overloads: one taking 'T', the second taking 'T *'. This used to be needed because of the interface...
github.com
Bad news - is a dooozy of a commit with lots of changes in there. And somewhere in there, is a breaking change.
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.
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:
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.
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)
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)
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.
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.
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.
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.)
(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.)