SGI: Development

Well, SGI/Mozilla did the original NSPR port. That NSPR port is an absolute mess though, as it tries to use IRIX's own thread library vs. pthreads. I rewrote parts of NSPR to tie in the unix_pthreads layer, and then added additional functionality. Specifically, spidermonkey's garbage collector walks through the stacks of running threads looking for things to run. Because of this, SpiderMonkey needs to be able to know where a stack's address space and location is. I fixed this by having SpiderMonkey use NSThread's library, which in my port where pthreads with a special struct attached to them. When the thread is created, it manually sets the address space and stack size of the thread, and stores them in the struct, so I can retrieve it later.

It's a pretty elegant hack IMHO. Spidermonkey (mostly) passed its test suite with additional patching.

XPCom was a stub in my version, since I needed libxul.so to exist so I can run test suite to figure out how far I could get. XPCom needs to know the C and C++ ABI of a given architecture/operating system. There was a version of XPCom for MIPSpro, but GCC has a different C++ ABI, so I knew that would fail. To fix it would require reverse engineering the proper function prologs and epilogues. Generally if you can XPCom+spidermonkey to pass its test suite, there is a pretty decent chance the damn thing might actually run.

Looking at my old messages, diegel got a dump of the hard drive from the box I did the porting, though I don't know how much code he reused. From the earlier discussions, the issues was with Firefox was that it linked, but fell over mysteriously. I think this was the issue I ran into the pthreads library I hit in Spidermonkey; specifically IRIX is extremely sensitive to the linking idea, and re-writing the linking order via _RLD32 magic variables was able to get it to work.

diegel is using gcc, so he must have solved the ABI issue (you can't do xptcalls without it, and xptcalls haven't changed in aeons).

That's a clever solution to JS GC.

I could still reconstruct appliable changesets (I guess this calls for porting hg to nekoware ), if you have the source tree you were working with in any form. This sounds highly doable. For TenFourFox, I just distribute changesets overlaid on top of -esr10/17/etc., and I think the same approach works here.

Well, I still do have all the stuff you did, let me know if you want it in any form...

Hrm, its possible xpcom between MIPSpro/GCC might be compatible. I never looked into the C++ breakage issue with GCC, but if it was just a managling issue vs. an actual change in calling convention, then its possible it "just might work". Would make life a LOT easier than writing a new one from scratch.



A tarball might be nice to fish to recover patches, and possibly some of the hand-built binaries I rolled.

I would love a tarball. I can reconstruct changesets from that manually. PM me!

PM sent.

I have the original file I already gave to diegel a while ago, up to you if you want it from him or from me (he might have done some extra work on it meanwhile, I'm not sure).
PM me if you want it, I will most likely create a torrent file and share it this way.

NCommander, this is a dump from the first machine you worked on, before I moved you from O200 to O2 (I think you haven't made any progress since the move)

I'm going to note that most of that code is extremely messy and somewhat of a trainwreck. I couldn't get hg -OR- quilt to work properly so I planned to generate one diff at the end and split that into individual patches. I do hope you don't find it too ugly .

I'd be willing to take another stab given access to an IRIX box capable of 64-bit code (and if I can get gld to work well enough to not be a piece of crap).

The other option is to try porting Fx4 (which has the advantage of its own repo) first. It doesn't require --enable-libxul, so a 32-bit linker will still handle it. That could facilitate a stepwise approach.

Currently I don't have the time to spent much work on porting software for Irix. But I like to share my knowledge. My firefox 3.0.19 build based on the patches posted in this forum:

viewtopic.php?f=15&t=16722370
viewtopic.php?f=15&t=16722189
viewtopic.php?f=15&t=16718674

I only fixed some of the bus errors. I build it with gcc 4.7 and mips pro but finally decided to package the gcc build, because the mips pro build had a lot of more problems to fix and there was no performance advantage. If someone want to package a mips pro build this should be not a big deal. You should use the libmozjs from my gcc build, since there were optimization problems within the libmozjs at least since firebird times. The current firefox2 also uses a gcc build javascript library.

firefox 3.5.19 compiles with the patches posted in this forum, but it doesn't start because of several assertion errors. There is no difference if you build it with gcc or mips pro. I don't spent much time into debugging this until now. I think it is worth to invest some time into firefox 3.5 since it uses a much more improved javascript version.

I also have a xfs dump of the build system of Ncommanders firefox10 port. His work doesn't based on the known patches, he seems to start completely from scratch. libxul linking fails with a memory error. Probably you can link it with debugging switched off, but from my point of view it makes no sense to port firefox with debugging disabled. Ncommanders work is based on gcc only. JanJaap mentioned that there is a 64 bit linker, that should be able to link larger object, but as far I understand this correctly it is for the 64 bit abi only. A basic Irix 64bit NSPR port exists in the mozilla sources, but this is very old and there is still a lot of work to build a 64bit firefox.

Finally I think it is worth to spent some time on the webkit port of bplaa.yai. He also had problems with the javascript stuff. It think there is a fair chance this code just work with gcc:

viewtopic.php?f=15&t=16726801&p=7351745&hilit=qt#p7351745

Thanks, I have that xfsdump now. However, the links to patches in those threads don't appear to work. Did someone else collect those?

TraceMonkey, particularly in 3.6 and 4, should be very easy to port to MIPS. We did it for PowerPC and that was enormously successful.

Yes there are some dead links to old patches. Attached you find all patches I know. Also please take a look at my firefox3 release notes.

I didn't use the FF3 work since a lot of it wasn't directly revelent (a *lot* was trying to get MIPSpro working with FF3), and the issues I had were different as FF3 hadn't started stripping out IRIX code all over the place.

Thanks, diegel!

FF still does this to some extent, by the way -

Not nearly as badly as before but on occasion ... the strange thing is, it often dies while sitting there quietly minimized. I'll be doing something else entirely, look up, and it's gone again. The LAN isn't locked down as tight as a cleveland girl collection but the Fox shouldn't be wandering unsupervised through the Internet, I hope

I suspect firefox itself is running out of address space. Older versions of Firefox were notorious RAM hogs and would sometimes leak memory, and with default settings, a 32-bit binary running under IRIX only has approximately 1 GiB of address space, part of which is taken up by the multiude of shared libraries and other fun stuff. I won't be suprised that firefox starts having malloc()s fail, and take a dive.

If you can get a gdb trace, it should be pretty obvious on why its self-destructing.

Since I've started to follow this post I'm getting more and more hooked with IRIX again. If there is a new tarball available, and if it help, I guess I could try some quick tests here with IP30. Good luck with the port.

All the best,
Diego

As it stands, I don't currently have an IRIX box or access to a machine to do any porting work so it as, at best, on ice :-/.

Hey there!

...well, if you think it is usable to continue with the development, I can setup an account for you on my Octane. Of course it is not the fastest gun around... ...but ...I guess it is something. Oh, and it has the full MIPSPRO install.

All the best,
Diego

If its not too much of an issue, I'd like to take a stab at it again. My SGI foo is a bit rusty; the Octane can run 64-bit binaries, correct?

If binutils is truly fixed for IRIX (or at least I can work out how to fix it), and get a 64-to-32 bit toolchain, firefox porting enters the realm of possible.