fails to build on sparc because of use of solaris only symbol |sync_instruction_memory|

Bug #411439 reported by Alexander Sack
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
XULRunner
Fix Released
High
xulrunner-1.9.1 (Ubuntu)
Fix Released
High
Alexander Sack

Bug Description

Binary package hint: xulrunner-1.9.1

build failure is here:

http://launchpadlibrarian.net/30113279/buildlog_ubuntu-karmic-sparc.xulrunner-1.9.1_1.9.1.2%2Bnobinonly-0ubuntu3_FAILEDTOBUILD.txt.gz

anojit/Native.h:122:22: warning: anonymous variadic macros were introduced in C99
rm -f libmozjs.so
g++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -fstrict-aliasing -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jsinvoke.o jsiter.o jslock.o jslog2.o jsmath.o jsnum.o jsobj.o json.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o jstracer.o Assembler.o Fragmento.o LIR.o RegAlloc.o avmplus.o NativeSparc.o jsbuiltins.o -lpthread -Wl,-Bsymbolic-functions -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm -lm -ldl
Assembler.o: In function `nanojit::Assembler::endAssembly(nanojit::Fragment*, avmplus::List<unsigned int*, (avmplus::ListElementType)0>&)':
/build/buildd/xulrunner-1.9.1-1.9.1.2+nobinonly/build-tree/mozilla/js/src/./nanojit/Assembler.cpp:975: undefined reference to `sync_instruction_memory'
collect2: ld returned 1 exit status

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Mono has something to deal with that on non solaris in mono/mono/mini/mini-sparc.c:mono_arch_flush_icache().

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

FTR, that's what mono does (for an equivalent to sync_instruction_memory (code, size);):
 guint64 *p = (guint64*)code;
 guint64 *end = (guint64*)(code + ((size + 8) /8));

 /*
  * FIXME: Flushing code in dword chunks in _slow_.
  */
 while (p < end)
#ifdef __GNUC__
  __asm__ __volatile__ ("iflush %0"::"r"(p++));
#else
   flushi (p ++);
#endif

Revision history for this message
In , Raúl Porcel (armin76) wrote :

@sun.com guys:
please fix the mess you did.

Revision history for this message
In , Leon-sha (leon-sha) wrote :

Created an attachment (id=375123)
patch

Revision history for this message
In , Leon-sha (leon-sha) wrote :

(From update of attachment 375123)
Raúl, I don't have linux on sparc. Can you try this patch to see if it works on linux. Thanks a lot.

Revision history for this message
In , Raúl Porcel (armin76) wrote :

Created an attachment (id=375329)
backtrace.txt

Well, it compiles, but unfortunately it sigbuses. I'm attaching the backtrace.

Thanks for the effort :)

Revision history for this message
In , Leon-sha (leon-sha) wrote :

(In reply to comment #6)
> Created an attachment (id=375329) [details]
> backtrace.txt
>
> Well, it compiles, but unfortunately it sigbuses. I'm attaching the backtrace.
>
> Thanks for the effort :)
Well, this is a little bit complicate. I can not resolve this by guessing. I need to find a linux box to do some debugging.

Revision history for this message
In , Leon-sha (leon-sha) wrote :

Created an attachment (id=376872)
patch 2

This is the patch for tracemonkey.

Revision history for this message
In , Dennis-ausil (dennis-ausil) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4
Build Identifier:

sparclinux libc does not have sync_instruction_memory the attached patch add support for sparc linux so it will again be buildable.

Reproducible: Always

Steps to Reproduce:
1. compile
2.
3.
Actual Results:
build fails with missing symbol

Expected Results:
compilation to succeed

Revision history for this message
In , Dennis-ausil (dennis-ausil) wrote :

Created an attachment (id=386822)
patch to add sync_instruction_memory

Revision history for this message
In , Reed Loden (reed) wrote :

Not sure if this is the right component or not...

Revision history for this message
In , Andreas Gal (gal) wrote :

(From update of attachment 386822)
Ed, you guys might want this too.

Revision history for this message
In , Edwsmith (edwsmith) wrote :

(From update of attachment 386822)
added tamarin bug 502642 to track this one

Revision history for this message
In , Leon-sha (leon-sha) wrote :

*** Bug 486584 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Leon-sha (leon-sha) wrote :

For the crash issue we'd better file another bug to track it.

*** This bug has been marked as a duplicate of bug 502369 ***

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(From update of attachment 386822)
>+ asm("flush %0" : : "r" (p));

IMHO, this should be made volatile. And iflush might be more appropriate than flush, if I'm not mistaken.

Revision history for this message
In , Leon-sha (leon-sha) wrote :

Someone mentioned here using iflush
https://bugzilla.mozilla.org/show_bug.cgi?id=486584#c2
And in solaris code flush is used.
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/sparc/gen/sync_instruction_memory.s
I think both is OK.

>+ p += 32;
I don't understand why it is 32 here. Should be 8.

Revision history for this message
In , Lhansen (lhansen) wrote :

(In reply to comment #6)
> (From update of attachment 386822 [details])
> >+ asm("flush %0" : : "r" (p));
>
> IMHO, this should be made volatile. And iflush might be more appropriate than
> flush, if I'm not mistaken.

In the Sparc v8 and v9 manuals it is called "flush"; it was called "iflush" in v7. Presumably the old name lives on in various assemblers.

Revision history for this message
In , Davem-redhat (davem-redhat) wrote :

Nobody will ever make a sparc V9 chip with an I-cache with line sizes
smaller than 32-bytes.

Doing it 8 bytes at a time is simply a bunch of wasted full pipeline flushes.

That's why we iterate 32-bytes at a time.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to comment #9)
> Nobody will ever make a sparc V9 chip with an I-cache with line sizes
> smaller than 32-bytes.

Is spidermonkey targetted at v9+ only, now ?

Revision history for this message
In , Davem-redhat (davem-redhat) wrote :

If you find even one person running this code on a V8 or earlier
Sparc processor, I will buy you a multi-million dollar penthouse
condo overlooking Central Park in New York City.

Revision history for this message
In , Robert-accettura (raccettura) wrote :

(In reply to comment #11)
> If you find even one person running this code on a V8 or earlier
> Sparc processor, I will buy you a multi-million dollar penthouse
> condo overlooking Central Park in New York City.

Well this machine is only $49.

http://cgi.ebay.com/Sun-SPARCstation-5-96MB-microSPARC-II-CD-ROM-FDD_W0QQitemZ390063492867QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item5ad1988f03&_trksid=p3286.c0.m14&_trkparms=65%3A12|66%3A2|39%3A1|72%3A1234|293%3A1|294%3A50

Will you cover moving costs?

Revision history for this message
In , Wes Garland (wesgarland) wrote :

@Mike & David: I have proposed deprecating SPARC V8 support entirely as part of the fix for bug 502696.

@Robert: The fastest SPARCstation 5 ever made ran at 170MHz and the 170MHz doesn't even run on Linux as it doesn't support the Fujitsu TurboSPARC (for whatever reason).

To put this in perspective, I tried to today to run Firefox on a multi-core 400MHz UltraSparc-II system (significantly faster clock rate and 3 times as many instructions per cycle). Technically speaking, it was usable, but 30 seconds to render "google.com" is not encouraging.

Besides which, NativeSparc.cpp already emits V9 instructions. So assuming that the CPU in use is an ultrasparc is completely safe.

Revision history for this message
Alexander Sack (asac) wrote :

Binary package hint: xulrunner-1.9.1

build failure is here:

http://launchpadlibrarian.net/30113279/buildlog_ubuntu-karmic-sparc.xulrunner-1.9.1_1.9.1.2%2Bnobinonly-0ubuntu3_FAILEDTOBUILD.txt.gz

anojit/Native.h:122:22: warning: anonymous variadic macros were introduced in C99
rm -f libmozjs.so
g++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -fstrict-aliasing -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jsinvoke.o jsiter.o jslock.o jslog2.o jsmath.o jsnum.o jsobj.o json.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o jstracer.o Assembler.o Fragmento.o LIR.o RegAlloc.o avmplus.o NativeSparc.o jsbuiltins.o -lpthread -Wl,-Bsymbolic-functions -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm -lm -ldl
Assembler.o: In function `nanojit::Assembler::endAssembly(nanojit::Fragment*, avmplus::List<unsigned int*, (avmplus::ListElementType)0>&)':
/build/buildd/xulrunner-1.9.1-1.9.1.2+nobinonly/build-tree/mozilla/js/src/./nanojit/Assembler.cpp:975: undefined reference to `sync_instruction_memory'
collect2: ld returned 1 exit status

Revision history for this message
Alexander Sack (asac) wrote :

upstream patch available; ensure landing and cherry pick.

Changed in xulrunner-1.9.1 (Ubuntu):
assignee: nobody → Alexander Sack (asac)
importance: Undecided → High
status: New → In Progress
Changed in xulrunner:
status: Unknown → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xulrunner-1.9.1 - 1.9.1.3+build1+nobinonly-0ubuntu3

---------------
xulrunner-1.9.1 (1.9.1.3+build1+nobinonly-0ubuntu3) karmic; urgency=low

  * workaround LP: #411439 - build failure on sparc; we disable jit on sparc until
    bmo 502369 is really fixed for us
    - update debian/rules
  * workaround LP: #435560 - xpidl binary produced by gcc 4.4 crashes on
    powerpc if built using -Os optimization; we force -O2 on powerpc to
    workaround this
    - update debian/rules
  * require libwi-dev >= 29-2ubuntu6 for powerpc and sparc as it contains fixes
    for such long double 128 support archs. See LP: #435793
    - update debian/control

 -- Alexander Sack <email address hidden> Thu, 24 Sep 2009 14:03:12 +0200

Changed in xulrunner-1.9.1 (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
In , Edwsmith (edwsmith) wrote :

Is this patch still applicable to newly merged nanojit in tamarin-redux?

Revision history for this message
In , Edwsmith (edwsmith) wrote :

status anyone?

Revision history for this message
In , Edwsmith (edwsmith) wrote :

*** Bug 502642 has been marked as a duplicate of this bug. ***

Changed in xulrunner:
status: Confirmed → In Progress
Revision history for this message
In , Dennis-ausil (dennis-ausil) wrote :

Can someone please apply this patch

Revision history for this message
In , Lhansen (lhansen) wrote :

I'll take the action to land (if appropriate) or close (otherwise), though I do not have access to a sparc-linux system so I don't know how much testing I can really hope to do.

(Leon, feel free to take this back from me if you want.)

Revision history for this message
In , Lhansen (lhansen) wrote :

pushed: redux changeset: 2929:a27726496703

Changed in xulrunner:
status: In Progress → Fix Released
Revision history for this message
In , Cpeyer (cpeyer) wrote :

Engineering work item. Marking as verified.

Revision history for this message
In , Raúl Porcel (armin76) wrote :

This is needed on mozilla-1.9.2. Can we get this backported, please?

Thanks

Changed in xulrunner:
status: Fix Released → Confirmed
Revision history for this message
In , Lhansen (lhansen) wrote :

No longer a tamarin issue but a Mozilla nanojit issue.

Revision history for this message
In , Andreas Gal (gal) wrote :

reed, this is not part of the build. We don't ship on solaris. We should just land this imo.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to comment #23)
> reed, this is not part of the build. We don't ship on solaris. We should just
> land this imo.

just a nit: this is not a patch for solaris, but for linux on sparc processors.

Revision history for this message
In , Reed Loden (reed) wrote :

(In reply to comment #23)
> reed, this is not part of the build. We don't ship on solaris. We should just
> land this imo.

In general, approval is still required for landing on branches.

Revision history for this message
In , Andreas Gal (gal) wrote :

Rules and reality don't have to be mutually exclusive. We don't ship on linux (vendors do), even less so do we ship sparc, and the total number of linux sparc firefox users is probably between 2 and 5. But I guess it can't hurt to get approval (that's why I didn't touch your flag), so lets just wait until one of the drivers wanders by.

Revision history for this message
In , Reed Loden (reed) wrote :

(In reply to comment #26)
> We don't ship on linux (vendors do)

We most definitely ship on Linux. I only use mozilla.org builds, for one example.

Revision history for this message
In , Bsterne (bsterne) wrote :

(From update of attachment 386822)
We missed 1.9.2.2. Moving approval request forward.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created an attachment (id=435828)
Patch for 1.9.2

The code moved in 1.9.2, and is not in Assembler.cpp anymore. If that is going to land on 1.9.2, this is the patch.

Revision history for this message
In , Raúl Porcel (armin76) wrote :

Any news?

C'mon...its an easy fix

Revision history for this message
In , Anarchy (anarchy) wrote :

*** Bug 534608 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Raúl Porcel (armin76) wrote :

Another one bites the dust!

Changed in xulrunner:
importance: Unknown → High
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Comment on attachment 435828
Patch for 1.9.2

Let's try again for next round

Revision history for this message
In , Clegnitto (clegnitto) wrote :

Comment on attachment 435828
Patch for 1.9.2

a=LegNeato for 1.9.2.12. Please land only on the mozilla-1.9.2 default branch, *not* the relbranch.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :
Changed in xulrunner:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.