Closed Bug 258429 Opened 20 years ago Closed 16 years ago

Crash at startup on mips

Categories

(Core :: XPCOM, defect)

Other
Linux
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: glandium, Assigned: glandium)

References

Details

(Keywords: crash)

Attachments

(2 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7) Gecko/20040823 Firefox/0.9.3
Build Identifier: any

Running regxpcom or even firefox brings a segmentation fault on mips.

See http://bugs.debian.org/238705 for backtrace on regxpcom.

(Patch following)

Reproducible: Always
Steps to Reproduce:
Attached patch Patch fixing the bug (obsolete) — Splinter Review
Patch provided by Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>

Note that the xptcstubs_asm_mips.s.m4 file is removed.

Note that the .s file provided may compile with any version of GCC, so bug
addressed in bug #250472 could be closed as well.
I've mistaken, the debian report in description doesn't show a backtrace of the
crash occuring in xpcom stuff, but rather a crash occuring during shared object
loading, probably due to build problems.
Anyway, with properly built firefox/thunderbird/mozilla (with fixed versions of
gcc and binutils hopefully coming soon in debian unstable, the current ones just
fail to build firefox/thunderbird/mozilla), the crash really happens and is
fixed by the attached patch.
Note that the description was also mistaken : the bug applies to firefox and
thunderbird, and i assume, to mozilla as well.
Blocks: 250472
Severity: critical → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Comment on attachment 158196 [details] [diff] [review]
Patch fixing the bug

shaver, could you review?  For that matter, could you recommend an sr?
Attachment #158196 - Flags: review?(shaver)
Comment on attachment 158196 [details] [diff] [review]
Patch fixing the bug

I'll ask Pav to review, since I think he was the last one to hack this
seriously, and then SR when he's done.
Attachment #158196 - Flags: superreview?(shaver)
Attachment #158196 - Flags: review?(shaver)
Attachment #158196 - Flags: review?(pavlov)
cc'ing ppietro in hopes that he can test this on ps2 linux, which is the only
real mips platform we currently support with this code.
I'd be happy to!  Give me a day or so to test this.  
Can't get the code to build with the patch applied.  I'm using the Firefox 0.9.3
Release source.

I get this:

gcc -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-
long-long -pedantic -Wa,-xgot -pipe  -DNDEBUG -DTRIMMED -O2   -I../../../../../.
./dist/include/xpcom -I../../../../../../dist/include -I/home/paulp/firefox_sour
ces/mozilla/dist/include/nspr     -c -x assembler-with-cpp -o xptcinvoke_asm_mip
s.o  -c xptcinvoke_asm_mips.s
xptcinvoke_asm_mips.s:72: unterminated character constant
xptcinvoke_asm_mips.s:131: unterminated character constant
xptcinvoke_asm_mips.s:133: unterminated character constant
xptcinvoke_asm_mips.s:139: unterminated character constant
xptcinvoke_asm_mips.s:140: unterminated character constant
xptcinvoke_asm_mips.s: Assembler messages:
xptcinvoke_asm_mips.s:63: Error: unrecognized opcode `setup_gp'
as: bfd assertion fail ../../bfd/elf32-mips.c:2919
gmake[8]: *** [xptcinvoke_asm_mips.o] Error 1
gmake[8]: Leaving directory `/home/paulp/firefox_sources/mozilla/xpcom/reflect/x
ptcall/src/md/unix'


I have full assembler output if anyone needs it.

Just for reference, the PlayStation 2 Linux platform uses gcc 2.95.2, with make
3.79.1 and I've updated the stock Perl to 5.8.3.

If I can help in any way, just let me know.  The PlayStation is up and running.

Cheers,
Paul
The 2.95 toolchain is pretty old, and ps2linux has some peculiar
incompatibilities to normal Linux/MIPS. The "unterminated string" was fixed in
newer cpp versions. The missing SETUP_CP macro might be defined in a different
place, or not at all; in any case it expands to a ".set noreorder; .cpload $25;
.set reorder;" sequence.
Any luck with new patches for Paul to try out?
Well, with the small change mentioned before (replacing SETUP_CP with a ".set
noreorder; .cpload $25; .set reorder;" sequence) it may work, I'm not sure if the
"unterminated character constant" counts as warning or as error. FWIW, the
various mozilla-based packages in Debian build (and work) with this patch.
I hadn't realized that everyone was waiting for me to try this.  I'd be happy to
give this a shot.   

Let me make sure I understand what I need to do though.  What I'm going to do is
go thru the submitted patch file and replace all instances of SETUP_GP with a
".set noreorder; .cpload $25; .set reorder" sequence?

(Note - although the thread has been mentioning SETUP_CP, I believe you want
SETUP_GP, right?)

I will try this and let you know.

Cheers,
Paul
Yes, that's exactly what's needed. And of course you're right, it's SETUP_GP, not SETUP_CP.
Hmm - still doesn't compile.  I no longer see the SETUP_GP error, but I get this:

gcc -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-
long-long -pedantic -Wa,-xgot -pipe  -DNDEBUG -DTRIMMED -O2   -I../../../../../.
./dist/include/xpcom -I../../../../../../dist/include -I/home/paulp/firefox_sour
ces/mozilla/dist/include/nspr     -c -x assembler-with-cpp -o xptcinvoke_asm_mip
s.o  -c xptcinvoke_asm_mips.s
xptcinvoke_asm_mips.s:74: unterminated character constant
xptcinvoke_asm_mips.s:133: unterminated character constant
xptcinvoke_asm_mips.s:135: unterminated character constant
xptcinvoke_asm_mips.s:141: unterminated character constant
xptcinvoke_asm_mips.s:142: unterminated character constant
gmake[8]: *** [xptcinvoke_asm_mips.o] Error 1
gmake[8]: Leaving directory `/home/paulp/firefox_sources/mozilla/xpcom/reflect/x
ptcall/src/md/unix'
gmake[7]: *** [libs] Error 2
gmake[7]: Leaving directory `/home/paulp/firefox_sources/mozilla/xpcom/reflect/x
ptcall/src/md'

8< snipped a bunch of "Leaving Directories", etc. >8

Cheers,
Paul
Well, those appear to be caused by a broken cpp which tries to handle lines
starting with a hash sign as preprocessing directives, even if the hash sign
isn't in the first line. Thus it falls over mips assembler line comments (which
are started by a hash sign) if they contain a unmatched "quote", like in "can't"
in line 74. Replace the hash-started comments with C-style block comments ( /*
... */ , the assembler accepts them, too.) and things should work.
Comment on attachment 158196 [details] [diff] [review]
Patch fixing the bug

Clearing review until we have a patch that compiles
Attachment #158196 - Flags: superreview?(shaver)
Attachment #158196 - Flags: review?(pavlov)
Took out the ' and tried compiling again.  Now I get this:


mipsEEel-linux-gcc -I/usr/mipsEEel-linux/mipsEEel-linux/usr/X11R6/include -Wall
-W -Wno-unused -Wpointer-arith -Wcast-align -Wn
o-long-long -Wa,-xgot -pipe  -DNDEBUG -DTRIMMED -O2  
-I../../../../../../dist/include/xpcom -I../../../../../../dist/include -
I/home/paulp/firefox/mozilla/dist/include/nspr     -c -x assembler-with-cpp -o
xptcstubs_asm_mips.o xptcstubs_asm_mips.s
../../../../../../dist/include/xpcom/xptcstubsdef.inc: Assembler messages:
../../../../../../dist/include/xpcom/xptcstubsdef.inc:5: Error: Unknown
pseudo-op:  `.aent'
../../../../../../dist/include/xpcom/xptcstubsdef.inc:6: Error: Unknown
pseudo-op:  `.aent'
../../../../../../dist/include/xpcom/xptcstubsdef.inc:7: Error: Unknown
pseudo-op:  `.aent

8< snip a bunch more of these! >8

This was via a cross-compiler.  I am in the process of native compiling right
now.  (With only 32 megs, native compiles take longer!)

Cheers,
Paul
Native compile just finished.  Exactly the same error.

Cheeers,
Paul
(oops - should have posted the statement)

gcc -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -Wa,-xgot -pipe  -DN
DEBUG -DTRIMMED -O2   -I../../../../../../dist/include/xpcom
-I../../../../../../dist/include -I/home/paulp/firefox_sour
ces/mozilla/dist/include/nspr     -c -x assembler-with-cpp -o
xptcstubs_asm_mips.o xptcstubs_asm_mips.s
../../../../../../dist/include/xpcom/xptcstubsdef.inc: Assembler messages:
../../../../../../dist/include/xpcom/xptcstubsdef.inc:5: Error: Unknown
pseudo-op:  `.aent'
../../../../../../dist/include/xpcom/xptcstubsdef.inc:6: Error: Unknown
pseudo-op:  `.aent'


(etc., etc.)

Cheers,
Paul
Err, .aent is available in all GNU MIPS toolchains for a very long time (at least
since 1995, according to the binutils changelogs). It is possible to move from
.aent to .ent at a code size penalty, but I begin to doubt this should be done
jsut because of a such nonstandard toolchain.
I'll take the penalty.  How would one go about replacing .aent with .ent?  Is it
a simple substitution?

I have users waiting for a working, non-crashing build.  Anything to get around
this bug would be most welcome. 

As for the age of the toolchain, I get this:

[paulp@digicharat paulp]$ as -v
GNU assembler version 2.9-ee-990721 (mipsEEel-linux) using BFD version 2.9-ee-990721

which I interpret as being a 1999 date.  Could there be some other reason why
.aent is failing?  Like, maybe the xptcstubsdef.inc file is being built
incorrectly or something?  (Sorry if this seems like a stupid question - I'm not
a programmer - I'm a software test engineer.)

If it would help any, I can make an account available on my PlayStation 2.  It's
been connected to the internet pretty much 24/7 for the past month.

Cheers,
Paul

the change to AS worries me. fwiw i was planning to get access to a mips linux
box  this weekend.
I eliminated the use of m4 because cpp prepocessing plus mips gas internal macros are already occasionally confusing. Adding a m4 layer on top makes things  worse.
I can confirm that firefox from Debian works on MIPS with the patch applied.
martin: that's really useless. from the current bug comments, there's no way the patch is landing as is.

seufer@csv.ica.uni-stuttgart.de: is someone going to post a new patch? the number of proposed changes you guys are talking about is more than i can follow.
We've been using the following patch to get Firefox and Thunderbird working on mips lately, and for the most part, it works fine.  Bit slow on some of the low-end machines (i.e., O2).  But on an IP28 box (Indigo2 R10000), it runs pretty snappy.

Screenshot is here showing 1.5.0.4 running on said IP28 box (this was off of a bootable CD, though):
http://dev.gentoo.org/~kumba/mips/misc/firefox-ip28-mips64.png

We'd like to get this issue plugged so we've got another choice of a functional browser/mail client for the users.  Any idea what's needed to get one of these patches fixed up and into a form acceptable for inclusion?
I re-diffed our copy against trunk, and it applied pretty cleanly (only 9 lines of offset before re-diffing).
Attachment #228581 - Flags: review?(pavlov)
Ping?  I've recently tested 1.5.0.6 on an X-Based livecd and it worked well on an SGI Octane running 2.6.17.10, using this patch.  I recently did a rebuild for 1.5.0.7 (haven't tested it yet), but the CD will be uploaded soon (this weekend most likely) if anyone needs independent testing (only on select SGI machines, though).
Assignee: dbradley → nobody
QA Contact: pschwartau → xpconnect
What's the status of this patch being accepted into the tree?

It presently applies cleanly against the 2.0.0.1 source tree, and seems to prevent one build failure, although I won't know if it works for sure until my build machine (an Octane running a 175MHz R10000 CPU and 128MB RAM) finishes the compile.

Without the patch, the build dies compiling XPCOM, as seen here:
http://bin.longlandclan.hopto.org/index.cgi/20070102-194817-373cc0c6
You all need to vote this one up ... Shaver this is getting a bit crazy ... would you find someone to review and sr so it can be approved and commited please. This is not the only arch bug that has been waiting for months for review, super review, and approval.
(In reply to comment #29)
> You all need to vote this one up ... Shaver this is getting a bit crazy ...
> would you find someone to review and sr so it can be approved and commited
> please. This is not the only arch bug that has been waiting for months for
> review, super review, and approval.

Shaver isn't CCed, nor is Stuart, who is the current review requestee. You should make sure they before making comments you intend them to see.
It's been a while since I looked at this.  I will try the 2006-07-08 attachment on the current build tree and see what happens on PlayStation 2 Linux.

Cheers,
Paul
(In reply to comment #31)
> It's been a while since I looked at this.  I will try the 2006-07-08 attachment
> on the current build tree and see what happens on PlayStation 2 Linux.
> 
> Cheers,
> Paul

I'm not sure how valid a test on a PS2 is going to be for this, given the various...."quirks" involved with those systems (ancient kernels, ancient glibc, ancient toolchain, etc).  It's not too terribly difficult to track down an SGI O2 on eBay these days, with an R5000 processor (just avoid the ones without an L2 cache) and some memory (128MB min) to build this with.  Both Debian and Gentoo maintain installable mediums to get a modern and usable environment up for testing.  On Gentoo, we even have a bootable X LiveCD released a few months ago that includes Firefox 1.5.0.8 and Thunderbird 1.5.0.8 to demonstrate the effectiveness of the patch for these systems.

Granted, O2's are not very fast systems (You can't use the R10000/R12000 versions for this -- long story), but they'll give you a much more robust test of the resultant output binaries.
well, given that I wrote this code for ps2 linux I'd say it is a pretty valid test -- that said, i no longer have access to any mips linux machines so I'm probably not the best person to test and review this.
(In reply to comment #32)
> I'm not sure how valid a test on a PS2 is going to be for this, given the
> various...."quirks" involved with those systems (ancient kernels, ancient
> glibc, ancient toolchain, etc).  

Well, that's the platform I build for... ^_^;

I'm a maintainer of Mozilla/Thunderbird/Firefox/SeaMonkey builds for
PlayStation 2 Linux.  If you read thru the history of this bug, I was
specifically asked to test this patch, and part of decision to hold this patch
was due to the number of PS2 Linux users that would be negatively affected by
the original check-in.  

Currently, I can build and execute Firefox 1.5.x binaries with no major
problems.  This bug seems to only affect "first time" Firefox users with the
standard PlayStation 2 Linux distribution.  (i.e. it crashes during the new
user wizard, etc.)  Most users can just restart the Firefox binary, and continue past the crashes.

(I do have a debian-based PlayStation 2 linux distro - Black Rhino - that I use
a custom 2.4.17 mipsEEel kernel to test with, and IIRC, I don't see the crash
on that OS.  I'd be happy to do any research/documentation on crash reproduce
scenarios - PS2 Linux vs. Black Rhino, 2.2.1 vs 2.4.17, old network adapter vs.
new network adapter - if that would be helpful.)

NOTE:  I'm not necessarily arguing against approval of the patch.  I was
initally asked to report on the suitability of the patch for my system, and I'm
always happy to try patches/builds and report back on the findings. ^_^  

At this point in time, I'm kinda thinking that perhaps the best solution is to check in the patch (pending other platform approval) for Firefox 2.0 - which I haven't really been able to build - and leave it out for Firefox 1.5.0.x, which is being discontinued in April anyway.  PlayStation 2 Linux is slowly dwindling for a number of reasons - mainly the inability of the new slim-line PS2s to use the HDD, discontinued sales of the Linux kit in North America, and the availability of modern PowerPC linux distros (Yellow Dog, Fedora Core) for the PS3.

Cheers,
Paul

P.S.  If you're curious, the Sony PlayStation 2 Linux homepage that hosts my
builds is here:
http://playstation2-linux.com/projects/mozilla-ps2
(In reply to comment #34)
> (In reply to comment #32)
> > I'm not sure how valid a test on a PS2 is going to be for this, given the
> > various...."quirks" involved with those systems (ancient kernels, ancient
> > glibc, ancient toolchain, etc).  
> 
> Well, that's the platform I build for... ^_^;
> 
> I'm a maintainer of Mozilla/Thunderbird/Firefox/SeaMonkey builds for
> PlayStation 2 Linux.  If you read thru the history of this bug, I was
> specifically asked to test this patch, and part of decision to hold this patch
> was due to the number of PS2 Linux users that would be negatively affected by
> the original check-in.  
> 
> Currently, I can build and execute Firefox 1.5.x binaries with no major
> problems.  This bug seems to only affect "first time" Firefox users with the
> standard PlayStation 2 Linux distribution.  (i.e. it crashes during the new
> user wizard, etc.)  Most users can just restart the Firefox binary, and
> continue past the crashes.
> 
> (I do have a debian-based PlayStation 2 linux distro - Black Rhino - that I use
> a custom 2.4.17 mipsEEel kernel to test with, and IIRC, I don't see the crash
> on that OS.  I'd be happy to do any research/documentation on crash reproduce
> scenarios - PS2 Linux vs. Black Rhino, 2.2.1 vs 2.4.17, old network adapter vs.
> new network adapter - if that would be helpful.)
> 
> NOTE:  I'm not necessarily arguing against approval of the patch.  I was
> initally asked to report on the suitability of the patch for my system, and I'm
> always happy to try patches/builds and report back on the findings. ^_^  
> 
> At this point in time, I'm kinda thinking that perhaps the best solution is to
> check in the patch (pending other platform approval) for Firefox 2.0 - which I
> haven't really been able to build - and leave it out for Firefox 1.5.0.x, which
> is being discontinued in April anyway.  PlayStation 2 Linux is slowly dwindling
> for a number of reasons - mainly the inability of the new slim-line PS2s to use
> the HDD, discontinued sales of the Linux kit in North America, and the
> availability of modern PowerPC linux distros (Yellow Dog, Fedora Core) for the
> PS3.
> 
> Cheers,
> Paul
> 
> P.S.  If you're curious, the Sony PlayStation 2 Linux homepage that hosts my
> builds is here:
> http://playstation2-linux.com/projects/mozilla-ps2
> 

This is making absolutely no sense at all. Mozilla claims they want to work closer with the linux distros right? Well the linux distros are telling you this patch is great it fixes the issue and does not introduce anything new. So where is mozilla working to get this on trunk so linux distros do not have to continue to patch it themselves?
arg. this bug is a classic example of how not go get something done.

first of all. *never* use reply. ever.

i considered forcibly landing this patch at the end of November. I decided against it.

This is my this my formal protest:
1. pavlov invited an expert he recognized to test the patch.
2. the expert explained that it didn't work.
3. people offered suggestions.
4. the expert explained that it still didn't work.
5. no one created a patch that claimed to address his problems.
6. this is *not* the kind of patch that would normally go into
cvs.mozilla.org because by any reasonable measurement, it's broken.

that said, i'd rather have fewer forks and it seems that thiemo is a
recognized contributor to major linux projects.

it also would have helped matters had someone asked thiemo to comment directly on this bug from the beginning so that at least he could explain what's going on, why he doesn't care, or possibly fix it to the satisfaction of the person to whom pavlov delegated review.

now if you have quibbles about who an expert is, i don't want to hear it. mozilla developers aren't omniscient, if we knew everything, we wouldn't have bugs like this. we rely on people with domain knowledge and pavlov had knowledge of the domain, so we relied on him to tell us who might be relevant.

in case it wasn't clear, I don't consider resurrecting a patch which people said wasn't correct to be "addressing" any review comments.
I figure the main source of confusion is that PS2-linux and the normal mips-linux are incompatible. This explains why your expert says "No, this can't ever work (on PS2)" while Debian, Gentoo and several commercial embedded Vendors use it happily for more than two years now.
The "Black Rhino" distro cited above might be Debian-based, but I figure it uses a toolchain and libc derived from the original PS2 Linux, so it remains binary incompatible to a stock Debian/MIPS, but can take advantage of R5900-specific features.
I'm not interested in the PS2 platform, and can't test PS2 specific code. So far I assumed the mips linux specific code was completely broken. Given that the current code works at least partially on PS2, would it help to rewrite the patch so it uses the old version for PS2 (IIRC mipsel-ee-*) and the new version for all other mips*-linux* configurations?
yes.
I think Thiemo's suggestion of having PS2-specific code in another section is the only sane way to do it, given the oddities of the PS2.  You can almost guarantee that if the CHOST is along the lines of mipsEEel-linux-*, you're looking at a PS2.

http://bin.longlandclan.hopto.org/index.cgi/20070103-235531-2eb4ffaf <-- I can confirm the above mentioned patch produces a perfectly operational build of Firefox.

Personally, however it gets done, does not bother me.  I just feel that having Firefox build out-of-the-box on MIPS will be beneficial to both Mozilla and the Linux/MIPS community.

I'm happy to organise access to test machines if need be, although as Joshua pointed out, an O2 or Octane are around if you look, aren't terribly expensive (depending on who you buy from... I bought my Octane for AU$160 off eBay Australia), and will provide a very reliable test platform for which to test Mozilla.  Even an R4400 or R5000 Indy with XL graphics, sufficient RAM and disk, will do a reasonable job as a test machine.
Hi everyone,

Quick update.  I was successfully able build Firefox 2.0.0.1 natively in PlayStation 2 Linux with the standard, unpatched source.  (Yay!!!) 

The startup crash still occurs - this is just a confirmation that the standard source tree compiles for the PS2 Linux platform.  

I've now applied the patch to the source tree, and will kick off a build.  I'll keep you posted.

Cheers,
Paul

Comment on attachment 228581 [details] [diff] [review]
Updated version against cvs trunk for mips

i'm going to clean this one out of my request queue. get a patch that works for ps2 and normal mips and i'll review.
Attachment #228581 - Flags: review?(pavlov) → review-
Can we look at treating the PS2 as its own arch just about (it already has its own CHOST), and look at getting this patch into the tree for the more common mips systems (SGI, mostly), and when someone with a functioning PS2/Linux install can pin down what changes it needs, get those in separate?

Neither Gentoo nor Debian officially support the PS2 as an installable target (though BlackRhino is Debian based) -- we target SGI systems mostly As this is what is most readily available on eBay and at Universities (where I've heard of our uses getting them from), and odds are likely (though this assumption is drawn from a certain lower oriface w/o any statistical data to back it up) that we have more users running SGI systems, that can support X, than people wanting to run Linux, let alone Mozilla programs, on a PS2.

That's not to say we haven't had a few stop by.  One guy even managed to get a gentoo stage2 done for the PS2Linux project once, but news of his work was posted to Slashdot, and the ensuing notoriety caused him to disappear before the work was ever completed (~Aug 2003).  To be quite honest, we've had more people showing up in our chatrooms lately seeking to know whether gentoo will run on embedded mips devices, like certain Linksys routers and Asus wireless devices.  The only knowledge I have regarding any recent system-level work on PS2Linux is a guy in our forums trying to port PS2 stuff to the 2.6 kernel (I think; he's still in the 2.4 one atm if memory serves me correctly).

Isn't there someone you guys know who either has access to, or owns an SGI System (Indy w/ XL graphics, O2 R5000, or Octane w/ Impact graphics) who can test our LiveCD for visual proof of Mozilla (Firefox, Thunderbird) running?  Heck, you can play FreeCiv or PySol while Firefox loads :)
This patch (presently untested... I'm about to get a machine compiling it now) combines both the existing MIPS code, and Thiemo's patch.

In Makefile.in, there is logic to check if Mozilla is being compiled on a PS2.  If it detects mipsEE in the CHOST, it switches to the original code presently in trunk.  Otherwise, it uses Thiemo's implementation, which is known to work on generic Linux/MIPS.

As I say, the patch is presently untested, I'm just about to start a build with this patch.  You might want to have a look at it on PS2Linux in the meantime.  If it builds and works on both platforms, we should be in business. :-)
I'll get started on a PlayStation 2 Linux build.  

Cheers,
Paul
Patch seems to fail for native builds of PS2 Linux.  From the failure, it's calling in the "normal" mips code.

Looks like the mipsEE test is not valid for a native PlayStation 2 Linux build... 

(I'm sorry - I'm not a programmer as much as a build engineer, so bear with me here.)

When I cross-compile, and create an archive, they're named mipsEEel (e.g. firefox-1.5.0.4.en-US.linux-mipsEEel-gtk1.tar.gz) - but when I compile natively - I get mipsel (e.g. firefox-1.5.0.4.en-US.linux-mipsel-gtk1.tar.gz)

Is this the flag you're checking against?

This may also be a case of too many patches and unpatches.  I'll clean my tree and start over.  More info soon.

Cheers,
Paul
Update:  Patch is definitely broken for PlayStation 2 Linux builds.  Manually verified that my source tree was an unpatched 2.0.0.1 tree, and built Firefox successfully.  

(If you're wondering why I didn't start from scratch, a standard Firefox build on native PlayStation 2 Linux takes about two days...)

Applied the latest patch, and the build failed:

gcc -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-
long-long -pedantic -Wa,-xgot -pipe  -DNDEBUG -DTRIMMED -O2   -I../../../../../.
./dist/include/xpcom -I../../../../../../dist/include -I../../../../../../dist/i
nclude/nspr    -c -x assembler-with-cpp -o xptcinvoke_asm_mips.o  -c xptcinvoke_
asm_mips.s
xptcinvoke_asm_mips.s:72: unterminated character constant
xptcinvoke_asm_mips.s:131: unterminated character constant
xptcinvoke_asm_mips.s:133: unterminated character constant
xptcinvoke_asm_mips.s:139: unterminated character constant
xptcinvoke_asm_mips.s:140: unterminated character constant
xptcinvoke_asm_mips.s: Assembler messages:
xptcinvoke_asm_mips.s:63: Error: unrecognized opcode `setup_gp'
as: bfd assertion fail ../../bfd/elf32-mips.c:2919
gmake[8]: *** [xptcinvoke_asm_mips.o] Error 1
gmake[8]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom/reflect/xptcal
l/src/md/unix'
gmake[7]: *** [libs] Error 2
gmake[7]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom/reflect/xptcal
l/src/md'
gmake[6]: *** [libs] Error 2
gmake[6]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom/reflect/xptcal
l/src'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom/reflect/xptcal
l'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom/reflect'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory `/home/paulp/mozilla2.0/mozilla/xpcom'
gmake[2]: *** [tier_2] Error 2
gmake[2]: Leaving directory `/home/paulp/mozilla2.0/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/paulp/mozilla2.0/mozilla'
make: *** [build] Error 2
[paulp@digicharat mozilla]$ 

This is what happens when the standard patch is applied to the source tree for PlayStation 2 Linux.

There is a chance the latest patch may work on cross-compile - but I won't be able to test that for a few days.

Let me know if you have any questions.

Cheers,
Paul
Right... that's highly unusual.  I made the (perhaps wrong) assumption that PS2 Linux used the 'mipsEEel-unknown-linux-gnu' CHOST everywhere, both native userland and cross-compiled.  It appears this is not the case.

What does `uname -a` report?  Perhaps there's some tag that ./configure can look for in the OS version string that can identify a PS2?  `uname -i` in particular may be helpful.  I get the following when running the command on my IP28:

> stuartl@beast ~ $ ssh fullhouse.local uname -i
> SGI Indigo2

My hunch, is that the PS2 will report "PlayStation2" or something similar, which we can look for.  Thoughts anyone?

As for not starting from scratch... I can understand that... it takes almost that long on an Octane or O2.  This is with 128MB RAM, I'd hate to try a build with only 32MB RAM.  I'm amased oomkiller doesn't nuke the build.
`uname -i` likely won't work for them -- our (meaning gentoo's) coreutils package includes a patch to cut out portions of /proc/cpuinfo and append it into uname output.  Likely, the stock coreutils (or the original split-packages, findutils, etc..) will reports "... mips unknown ..." in their output.  You'd actually need to poke into /proc/cpuinfo instead.

That said, though, if memory serves, I recall the processor/system type being reported as "EE" (for the EmotionEngine).
Hi!

uname -a gives me this:

[paulp@digicharat paulp]$ uname -a
Linux digicharat 2.2.1 #1 Wed Nov 14 18:28:00 JST 2001 mips unknown

uname -i didn't give me any output - it errored out instead. 

/proc/cpuinfo gives me this:

[paulp@digicharat /proc]$ cat cpuinfo 
cpu                     : MIPS
cpu model               : R5900 V3.1
system type             : EE PS2
BogoMIPS                : 392.40
byteorder               : little endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

Hope this helps! 

Cheers,
Paul
(In reply to comment #49)
> [paulp@digicharat paulp]$ uname -a
> Linux digicharat 2.2.1 #1 Wed Nov 14 18:28:00 JST 2001 mips unknown

2.2.1?  Wow that's old.

> [paulp@digicharat /proc]$ cat cpuinfo 
> cpu                     : MIPS
> cpu model               : R5900 V3.1
> system type             : EE PS2
^^ Bingo...

Now the question remains: is it viable to grep for 'EE PS2' in /proc/cpuinfo from the configure scripts?  If cross-compiling, obviously not... however, if `uname -m` reports 'mips', I think it's safe to assume we're compiling natively, and thus can poke around in /proc/cpuinfo to detect if it's a PS2 or not.

In ./configure... it'd look like:

if [ "$( uname -m )" = "mips" ]; then
   if grep -q 'EE PS2' /proc/cpuinfo; then
      # Do something that enables PS2 support
   fi
fi

How to do this with autotools, I'm not exactly sure.  I'm a bit of a newbie when it comes to autotools. :-)

Thoughts people?  It looks like we might have something here.
Hiya!

Yeah - 2.2.1 is pretty old. ^_^

We do have a 2.4.17 kernel, courtesy of Sony Japan's Broadband Navigator for the PS2, that we can use.  But - there's a few ps2-specific developer libraries that only seem to work with 2.2.1. Also - 2.4.17 doesn't like the Network Adaptor that came with the Linux kit - you have to use the standard Network Adaptor.  The kernels seem to be hard coded against specific network hardware.

I switch back and forth - it doesn't affect basic Linux operation - but for maximum compatibility, I'll load up the 2.2.1 kernel.

uname -m gives me this:
[paulp@digicharat paulp]$ uname -m
mips

which is what you expected. ^_^

Cheers,
Paul
(In reply to comment #50)
> if [ "$( uname -m )" = "mips" ]; then
>    if grep -q 'EE PS2' /proc/cpuinfo; then
>       # Do something that enables PS2 support
>    fi
> fi

you should test $OS_TEST instead of uname -m, and you can know if you're cross-compiling by testing $CROSS_COMPILE
Right... now we're getting closer to our aim I think. :-)

if [ "$OS_TEST" = "mips" ]; then
   if grep -q 'EE PS2' /proc/cpuinfo; then
      # Do something that enables PS2 support
   fi
fi

Now... how would one go about adding say... a $SUBARCH variable or similar that can be seen from the Makefiles?  Presumably there's more to it than just saying SUBARCH=ps2.  (SUBARCH might be the wrong name at this point)

It's quite likely a similar hack will be needed if we decide to support Mozilla on MIPS n32/n64, as both use the mips64 CHOST prefix.  Of course... we'll cross _that_ bridge when we reach it. :-)
If we get in n32/n64 xpcom patches, I don't think we'll have to worry about the PS2 at that point, since no Linux kernel boots it in 64bit mode :)
Okay, my box finally finished compiling Firefox 2.0.0.1

 * www-client/mozilla-firefox

     Fri Jan 19 02:15:32 2007 >>> www-client/mozilla-firefox-2.0.0.1-r2
       merge time: 11 hours, 52 minutes.

I'm posting this message with the freshly built version of Firefox, and so far so good.  Everything appears to work.  This is with the patch I added in comment #43.

The patch above should work for cross-compiled builds, since all the assumptions about CHOST hold.  Presumably if it compiles there, it's just a matter of adjusting the build system to detect a PS2 when compiling natively.
I am highly amused by the R5900 centricity of this whole thread.  Sony and TAEC (who actually did develop the CPU in San Jose, California) made a sufficient number of highly odd design decissions that either enforce it to be binary incompatible with the rest of the MIPS world or running at just a fraction of its potencial CPU power.  I omit the technical details here but as the kernel maintainer I can only say I'm not too unhappy that nobody never decieded to send me patches - nor do I expect to ever see any patches.  Too many promised that were ever fullfilled to even the smallest degree.  Add the 32MB of memory - for a modern browser of the mozilla family that's basically a joke.

Get real.  Forget about the PS2.  As for Linux it's about as dead as PS/2.  It's just some dinosaurs need a little longer to realize they're extinct ;-)
I'll add some comments/opinions here. 

Recently, I provided some Sony NDA-safe hardware technical assistance to a Linux enthusiast in Brasil who then managed to get PlayStation 2 Linux working from a USB hard drive on one of the SlimLine PS2s - the PS2s that are supposed to be unable to run Linux.  The enthusiast then posted their procedure for doing this on the web.  

Also, Sony's PlayStation 2 Linux Community (http://playstation2-linux.com) website is still on-line, and my builds are still available.

From this, it would seem to me that there is still some interest in the platform - especially considering how popular the SlimLine PS2s are worldwide - but probably not in enough numbers to justify further Firefox/Mozilla.org involvement.  

As far as this bug - this is what I know: 1.) Firefox used to work on the PS2 just fine; 2.) It broke, and a bug was filed; 3.) I was asked to test a possible patch as the maintainer of Firefox/Mozilla for PS2 Linux; 4.) The patch broke my build, which I duly noted; 5.) Some developers then proposed a system to allow me to build around the patch; and 6.) As far as I can tell, that solution w/patch is not quite completed yet.

Personally, I feel that the bug is minor enough, and the userbase is small enough, that I have no problems with the solution outlined in point #5 above. Alternatively - a simpler code fix might be in everyone's best interest, but at this point it's looking unlikely that this will happen, and I'm sure the MIPS debian/gentoo folks are getting tired of manually patching around the original bug.

As always, I am happy to provide any build testing or PlayStation 2 resources for anyone who contacts me regarding this issue. (^_^)

Cheers,
Paul
Well... here's hoping that Linux/MIPS will start to become more popular, especially with affordable desktop computers based on MIPS (and MIPS-like) processors on the horizon.

The patch there basically treats the PS2 as a separate platform to standard MIPS machines -- which is the reality, despite being one of the family, it's a really bastardised CPU with lots of obscurities that make it incompatible with everything else.

Due to my lack of knowledge regarding the Mozilla build system, I'm not exactly sure where all the necessary bits need to go to allow detection of a native PS2 build environment, or indeed, a configure option that uses the PS2 code.

I'm not likely to obtain a PS2 in the near future ... they stopped selling the kits here in Australia years ago as well as the full-size PS2s to host the hard drives.  I dare say the situation is identical elsewhere.  We face the same issue with SGI MIPS kit; the situation being a little better, since SGI still sell refurbished kit, somewhat keeping the environment going, but I fear this too will probably dry up eventually.

So I think we're going to wind up moving to more modern hardware eventually, and the dear old PS2 will get left behind.  I therefore feel it would be prudent to get this patch in ahead of time, if need be, providing a configure option to enable compilation on a PS2 which should allow users to run Mozilla on their PlayStations with minimal or no patching, whilst also allowing users of more standard MIPS kit to do likewise.
ok, so does this work?

note: you need to regenerate configure.
Attachment #158196 - Attachment is obsolete: true
Attachment #228581 - Attachment is obsolete: true
Attachment #251728 - Attachment is obsolete: true
Attachment #266596 - Flags: review?(ppietro)
Comment on attachment 266596 [details] [diff] [review]
untested trunk cvs diff based on 251728

r- by req, SunOS 5.8 grep treats \W as literal W
Attachment #266596 - Flags: review-
(actually, that was a /usr/xpg4/bin/grep, /bin/grep didn't care for -E, /bin/egrep treats \W as literal W also)
Keywords: helpwanted
I will test this and let you know shortly.  I'm busy looking for a new job right now, so my weekly schedule's really busy - but I'd like to get this tested ASAP.

Cheers,
Paul
I'll try and test this on my end this weekend, time permitting, and make sure it works on our side.
Hi everyone,

I have some updates for you.  Currently, the PlayStation 2 is working on a default build of 1.5.0.12 - just to prove that the normal code builds correctly.  In the meantime, I tried patching various releases and builing native vs. cross-compiled, and they all failed.  

Here's a summary of what I've tried so far.

Cross-compiled:
1.5.0.12 & 2.0.0.4 : failed.  

Note - two hunks did not patch - but manual inspection indicated these hunks were specifically comment blocks of names, gpl license etc.  All major code sections patched successfully.  

I have complete output logs available, but the end looks like this:

<snip>
xptcinvoke_asm_mips.s:71: unterminated character constant
xptcinvoke_asm_mips.s:130: unterminated character constant
xptcinvoke_asm_mips.s:132: unterminated character constant
xptcinvoke_asm_mips.s:138: unterminated character constant
xptcinvoke_asm_mips.s:139: unterminated character constant
xptcinvoke_asm_mips.s: Assembler messages:
xptcinvoke_asm_mips.s:62: Error: unrecognized opcode `setup_gp'
/usr/mipsEEel-linux/mipsEEel-linux/bin/as: bfd assertion fail ../../bfd/elf32-mips.c:2919
gmake[8]: *** [xptcinvoke_asm_mips.o] Error 1
gmake[8]: Leaving directory `/home/paulp/firefox/mozilla/xpcom/reflect/xptcall/src/md/unix'
gmake[7]: *** [libs] Error 2
gmake[7]: Leaving directory `/home/paulp/firefox/mozilla/xpcom/reflect/xptcall/src/md'
gmake[6]: *** [libs] Error 2
<snip>

This would indicate that the incompatible MIPS assembler code is being invoked, which I think this patch is supposed to work around.

(BTW -- The current CVS tree is not able to build cross-compiled on my machine due to configure issues.  It seems that the current CVS build ignores the "ac_add_options --enable-default-toolkit=gtk" switch, and my cross-compile environment hasn't been setup to cross compile gtk2, etc.  Based on the memory footprint, and performance slowdown of advanced graphic kits for the PS2, I doubt I'll go thru the exercise of setting this up for the cross-compiler, either.  I have it set up for the native build environment, but PS2s prefer gtk. ^_^)

Native build:
1.5.0.12 : failed

Same note as above - 2 hunks failed on the patch, but these were in comment blocks, etc.

Different error this time - 

<snip>
rm -f libfdm.a
ar cr libfdm.a e_acos.o e_asin.o e_atan2.o e_exp.o e_fmod.o e_log.o e_pow.o e_rem_pio2.o s_scalbn.o e_sqrt.o k_cos.o k_sin.o k_rem_pio2.o k_tan.o s_atan.o s_ceil.o s_copysign.o s_cos.o s_fabs.o s_finite.o s_floor.o s_isnan.o s_lib_version.o s_sin.o s_tan.o w_acos.o w_asin.o w_atan2.o w_exp.o w_fmod.o w_loc  -DOSTYPE=\"Linux2.2\" -DOSARCH=\"Linux\" -DBUILD_ID=2007060516 -DEXPORT_JS_API  -DJS_USE_SAFE_ARENA   -I../../dist/include/js -I../../dist/include -I../../dist/include/nspr    -I../../dist/sdk/include -I. -I/usr/X11R6/include   -fPIC -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -Wa,-xgot -pipe  -DNDEBUG -DTRIMMED -O2  -I/usr/X11R6/include  jsapi.c
In file included from jsapi.c:49:
jstypes.h:234: #error "Must define one of XP_BEOS, XP_OS2, XP_WIN or XP_UNIX"
jstypes.h:250: #error No suitable type for JSInt8/JSUint8
jstypes.h:263: #error No suitable type for JSInt16/JSUint16
jstypes.h:283: #error No suitable type for JSInt32/JSUint32
jstypes.h:334: #error 'sizeof(int)' not sufficient for platform use
In file included from jsapi.c:49:
jstypes.h:315: parse error before `JSUint32'
jstypes.h:315: warning: no semicolon at end of struct or union
jstypes.h:317: warning: type defaults to `int' in declaration of `JSInt64'
jstypes.h:317: ANSI C forbids data definition with no type or storage class
jstypes.h:318: parse error before `JSUint64'
jstypes.h:318: warning: type defaults to `int' in declaration of `JSUint64'
jstypes.h:318: ANSI C forbids data definition with no type or storage class
<snip>

Again - full output logs are available.  

That's all I have so far.

Cheers,
Paul

P.S.  While attempting a control cross-compile - unpatched - I noticed that the latest 1.5.0.12 build fails in the NSS code.  Native builds work fine.  NSS used to cross-compile - last successful build I tried was 1.5.0.4.   I'll spend a little time narrowing it down to which version the build breaks and file a bug, if necessary.  (This should go to the NSS team, right?)
I managed a test of firefox-2.0.0.4 against this patch, and it works good.  I had the same failure against the hunks patching in the comments, but no compile failures.

So it looks like someone just needs to investigate the PS2 failures, patch them up, and I think we can finally start to wrap this bug up.
timeless, can you update the patch?
Attached patch Patch for !ps2Splinter Review
I don't have time to incorporate the PS2 stuff in, but FWIW, this is the current patch used on Debian for mips, including changes necessary after bug #349002.

It also depends on bug #434501.
Attachment #321605 - Flags: superreview?(benjamin)
Attachment #321605 - Flags: review?(timeless)
Attachment #321605 - Flags: superreview?(benjamin)
Attachment #321605 - Flags: superreview+
Attachment #321605 - Flags: review?(timeless)
Assignee: nobody → mh+mozilla
Component: XPConnect → XPCOM
Keywords: checkin-needed
QA Contact: xpconnect → xpcom
http://hg.mozilla.org/mozilla-central/rev/23d35cd4547b

Even though this doesn't fix the PS2, I'm marking this fixed as mips itself has been dealt with. If somebody still wants to get PS2 fixed, please open a new bug.
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
Keywords: helpwanted
In case people here are interested, there's a patch "for n32 ABI" (I don't actually know much about MIPS) in bug 482759.
Comment on attachment 266596 [details] [diff] [review]
untested trunk cvs diff based on 251728

Review of attachment 266596 [details] [diff] [review]:
-----------------------------------------------------------------

I actually reviewed this back in the day - apparently it never cleared out.  Clearing it now.
Comment on attachment 266596 [details] [diff] [review]
untested trunk cvs diff based on 251728

Review of attachment 266596 [details] [diff] [review]:
-----------------------------------------------------------------

Done.  Sorry about the confusion.
Comment on attachment 266596 [details] [diff] [review]
untested trunk cvs diff based on 251728

Review of attachment 266596 [details] [diff] [review]:
-----------------------------------------------------------------

Let's see if this closes it.
Comment on attachment 266596 [details] [diff] [review]
untested trunk cvs diff based on 251728

Review of attachment 266596 [details] [diff] [review]:
-----------------------------------------------------------------

Clearing review flag.  Marking as +, since it was done back in the day.
Attachment #266596 - Flags: review?(ppietro) → review+
You need to log in before you can comment on or make changes to this bug.