Created attachment 725732
If available, use SO_VERSION from configure env to set DLL_SUFFIX
Here's what i have in my wip port - same as what's in m-c.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/111
Finally \o/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To manage notifications about this bug go to:
https://bugs.launch
Created attachment 620274
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
That also works. New patch which only removes the #else #error from
ExecutableAllocator.h, tested working here on ppc.
--
You received this bug notification because you are a member of Ub
So that'd mean replacing :
#error "The cacheFlush support is missing on this platform."
by
static void cacheFlush(void*, size_t)
{
#warning "Using dummy generic & empty cacheFlush for this platform."
}
Do you think that'll work out ? Since from my understanding of the
previous comments cacheFlu
Created attachment 620233
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
So with this smaller patch (and also patches from 750447, 750620 &
750853..) i have a working firefox (Mozilla/5.0 (X11; OpenBSD macppc;
rv:15.0) Gecko/15.0 Firefox/15.0a1), browsed hg.m.o/
(In reply to Cameron Kaiser from comment #113)
> Can you change the ifsef WTF_CPU_PPC to defined(WTF_CPU_PPC) &&
> !defined(JS_CPU_PPC_OSX) around cacheFlush?
Sure, no problem.
I've sent the current patch to try here :
https://tbpl.mozilla.org/?tree=Try&rev=ec2fff3441e3
I'm not an expert for dec
Created attachment 619876
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
Fwiw here's the (simpler) patch i'm working on (no, i didn't gave up..) :
- it doesnt touch the ENABLE_ASSEMBLER hell -> shouldnt affect tier1 archs
- it uses the dummy empty cacheFlush imp
(In reply to Cameron Kaiser from comment #110)
> Landry, how close are you to a patch for this? I'd like to get bug 731110
> revised and landed with the next train so that downstreamers can get it and
> I can stop schlepping it around in our own changesets. It may actually
> simplify your work. If
(In reply to David Mandelin from comment #102)
> This is getting really confusing--I feel like I need to back up a few steps.
Yes, i'm also confused.
> 1. First off, do you still need to leave out the executableAllocators in
> jscntxt.h? If you have the JITs now, then it seems like you don't even
I've tried a slightly different approach in
https://tbpl.mozilla.org/?tree=Try&rev=49b9616807cc but looking at the
results it wasnt working 100%..
The idea (https://hg.mozilla.org/try/rev/96ce117be086) was to set
ENABLE_ASSEMBLER=1 through configure.in + config/autoconf.mk so that it
got applied a
(In reply to David Mandelin from comment #99)
> I would suggest making the minimal change that actually works and doesn't
> make things more confusing. Exactly what that would be, I don't know without
> trying things out. My *guess* would be that adding JS_ENABLE_JIT to
> Makefile.in and using it o
And looking at Makefile.in, the list of archs is really the same as
ENABLE_METHODJIT, so i'd be tempted to replace ifeq (,$(filter arm%
sparc %86 x86_64 mips%,$(TARGET_CPU))) by ifdef ENABLE_METHODJIT, or
even better merge the two blocks with the ENABLE_METHODJIT above.
Thoughs ?
--
You received
(In reply to David Mandelin from comment #95)
> Landry, it's definitely a maze. Sorting it out proper would be a lot of work
> so I definitely don't expect you to fix everything as part of this patch. It
> seems important to make sure ENABLE_ASSEMBLER is consistent, though, so
> combined with Mike
(In reply to David Mandelin from comment #91)
> (In reply to Mike Hommey [:glandium] from comment #90)
> > Yes. That these things are in Makefile.in is a mistake anyways.
>
> JSC sets those flags in what we imported as assembler/wtf/Platform.h, which
> seems reasonable. In fact, I see they set ENA
Sidenote : https://tbpl.mozilla.org/?tree=Try&rev=88122a478851 with
inclusion of jit/ExecutableAllocator.h in jscntxt.h is all green, so
we're definitely on the right track.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.
Trying to find a common denominator in the failing 9 tests :
some tests fail for all 9 combinaisons of jit_test.py arguments :
tests/basic/bug708805.js, bug713226.js, bug716013.js, bug728609.js,
bug729364.js
some fail for only 7 combinaisons out of 9, and goes into 2 classes :
the ones that fail
(In reply to Mike Hommey [:glandium] from comment #86)
> (In reply to Landry Breuil from comment #85)
> > (In reply to David Mandelin from comment #82)
> > > Landry, following up on a hint from billm, I got your patch to work on
> > > Linux
> > > with this addition:
> > >
> > > diff -r e7bbcbb6c2
(In reply to David Mandelin from comment #82)
> Landry, following up on a hint from billm, I got your patch to work on Linux
> with this addition:
>
> diff -r e7bbcbb6c24a js/src/jscntxt.h
> --- a/js/src/jscntxt.hTue Mar 13 17:42:33 2012 -0700
> +++ b/js/src/jscntxt.hTue Mar 13 18:
I've looked at try logs, and yes ENABLE_ASSEMBLER=1 is not set on the
commandline when building under shell/ with the patch.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thund
Try build still fails the same on debug builds only.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To manage notifications
Re-read the diff, and a bit out of ideas i've pushed a similar changeset
with s/#if ENABLE_ASSEMBLER/#ifdef ENABLE_ASSEMBLER/, but i doubt it'll
change anything.
https://tbpl.mozilla.org/?tree=Try&rev=ff2bd33b8476
To me, JS_METHODJIT includes ENABLE_YARR_JIT, so that chunk in
js/src/vm/RegExpObje
Just to make sure, i've pushed the offending diff to try with -b do -p
linux,linux64 :
https://tbpl.mozilla.org/?tree=Try&rev=d77a3095728e
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
The try builds on linux64 failed due to hg errors, i've asked the
rebuild but the linux debug build shows the same failure.
- what is the difference between debug and non debug builds in terms of JIT ?
ENABLE_ASSEMBLER and ENABLE_YARR_JIT are set in both on linux, from what i can
tell.
- the pat
(In reply to Mike Hommey [:glandium] from comment #71)
> Well, if it's breaking linux debug builds, it means it's *not* only
> shuffling ifdefs around. So you should start by checking that.
It shuffles ENABLER_YARR_JIT, adds #if ENABLE_ASSEMBLER around
execAlloc, ENABLE_ASSEMBLER is set on tier1 a
Created attachment 603278
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
And here's a proper hg changeset, applied on top of m-c, running fine as
"Mozilla/5.0 (X11; OpenBSD macppc; rv:13.0) Gecko/20120306
Firefox/13.0a1"
I took the liberty of removing the now u
patch #603183 reads good, applies fine on m-c. Doing a testbuild before
setting checkin-needed, results in ~6h.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTB
So, what's needed to fix this ? Sorry, i have no idea why it changes
behaviour for linux debug builds, since it's only shuffling ifdefs
around... and the testsuite log isnt really verbose, besides saying
there's a failure.
--
You received this bug notification because you are a member of Ubuntu
B
Set checkin-needed, carrying forward dmandelin's r+ on attachement
600506.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To
Review ping ? :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908508
Title:
Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre
To manage notifications about this bug go to:
https://bugs.l
(In reply to Landry Breuil from comment #55)
> Created attachment 600506
> Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
> supported (m-c patch)
>
> That was it, with this new patch the build goes past js/. Changes from last
> patch :
> - update after landing of #700822,
Most likely fallout of #717540, maybe because of the support
(supposedly, yes) of __attribute__((weak)) in our gcc..
Emmanueel, what's your compiler ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/908
Created attachment 600506
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
That was it, with this new patch the build goes past js/. Changes from last
patch :
- update after landing of #700822, ie enclose use of execAlloc_ withing #if
ENABLE_ASSEMBLE
ok i think i figured it out.. the patch readded Assertions.cpp to
CPPSRCS, which was gone from the ENABLE_YARR_JIT case in
https://hg.mozilla.org/mozilla-
central/diff/71d144fbd53e/js/src/Makefile.in. The breakage might be
because mfbt/ is in the search path, and it's that mfbt/Assertions.cpp
that
(In reply to Mike Hommey [:glandium] from comment #49)
> > Yes, except that YarrSyntaxChecker.cpp is in CPPSRCS only in
> > ENABLE_YARR_JIT case..
>
> Both your patch and my older patch add YarrSyntaxChecker.cpp to CPPSRCS in
> the non-ENABLE_YARR_JIT case
Yep, but YarrSyntaxChecker.h is only i
Yes, except that YarrSyntaxChecker.cpp is in CPPSRCS only in
ENABLE_YARR_JIT case.. i'll wrap up a patch removing that #ifdef, and
adding that cpp file to CPPSRCS in the !ENABLE_YARR_JIT case to see if
it helps. Patch has to be updated anyway since landing of #700822
--
You received this bug noti
Will that mean that !yarr-jit will become part of the 'regular
testsuite', so that build breakage are detected on tbpl ? Ill monitor
#661974, when you have something ready i'll try-compile it on ppc..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscrib
in bug #684559 comment 34, cameron kaiser talks about the possibility of
'unless simply trying to build it (+/- throwing away the result) is
acceptable.' to check syntax on !yarr_jit platforms, how would it be
achievable ?
--
You received this bug notification because you are a member of Ubuntu
B
And the build was successful, browsing maps.google.fr from my iBook G4
with http://buildbot.rhaalovely.net/builds/firefox-13.0a1.en-
US.openbsd5.1-powerpc.tar.bz2. Apart checkSyntax, it should be okay.
Chris, any idea what to do about that, and would it be so wrong to
return true, given that it wo
Comment on attachment 594798
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
Doesn't apply anymore since landing of bug #724748, since code was
shuffled a bit. I'll try to come up with a new patch. Sigh. Can someone
care a bit about that issue so that
Created attachment 596771
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
Grr mishmashed patch.. here's a correct one that at least should build js/.
Results in
http://buildbot.rhaalovely.net/builders/mozilla-central-macppc/builds/55
--
You receive
Created attachment 596748
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
Same patch, updated. Build results in a few hours (if anything else
didn't broke on exotic archs..) in
http://buildbot.rhaalovely.net/builders/mozilla-central-macppc/builds/54
how are you trying to build it jit-free ? those codepaths are not really
tested.. and armv7 falls in the case where ENABLE_ASSEMBLER should be
set, which builds ExecutablePool/Allocator code..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
Created attachment 594798
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
And here's a new updated patch after last commits to that area, which allows me
to build m-c on sparc64 and ppc, i've run dromaeo & kraken tests on ppc for a
bunch of hours wi
Since landing of bug #688069, previous patch (#591376) doesn't apply
anymore (regExpPrivateCode disappeared/was renamed ?). I have a bad
feeling about fighting for a lost cause, and chasing a moving target
i don't know the code nor how it works, and blindly adding #ifdefs while
trying to 'backp
Created attachment 591376
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
And here's the corresponding patch, ie porting mike's patch to -current, adds
#if ENABLE_ASSEMBLER around ExecutableAllocator definitions/uses (instead of
pulling assembler/Ex
(In reply to Mike Hommey [:glandium] from comment #29)
> Yes, but for sparc, it's more subtle: ENABLE_ASSEMBLER needs to be set for
> the normal non YARR JIT. Man, what a mess.
How is it a problem, since sparc is on the ENABLE_YARR_JIT side ? And even if
it wasn't,
that wouldnt be an issue if we
(In reply to Mike Hommey [:glandium] from comment #26)
> That's why ENABLE_ASSEMBLER needs to be off.
But if ENABLE_ASSEMBLER is conditional to
ENABLE_YARR_JIT|ENABLE_METHODJIT in Makefile.in, build fails in
jscntxt.{cpp,h}/jsprvtd.h due to missing def of struct
JSC::ExecutableAllocator (see comme
Created attachment 589953
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported (m-c patch)
Here's the patch updated to m-c, with the following changes wrt previous patch
against beta :
- return true instead of #error'ing in syntaxCheck. (no idea what to do for
that)
(In reply to Cameron Kaiser from comment #10)
> I'm good with that. We're using YARR JIT in PowerPC now anyway.
Can you detail how you achieved that (in TenFourFox i suppose), how
related is it to nanojit on ppc (#624164), and if the corresponding code
is commited to m-c, or candidate to be ? I'm
(In reply to Chris Leary [:cdleary] from comment #19)
> (In reply to Landry Breuil from comment #18)
> > Another annoyance was the landing of bug #673188, which right now #errors
> > out if ENABLE_YARR_JIT is unset (see RegExpObject.cpp, function
> > checkSyntax()), pretty unfriendly. So far i've r
For the record, the build failure on sparc64/ppc/!YARR_JIT is now on m-c
:
c++ -o jsanalyze.o -c -fvisibility=hidden -DOSTYPE=\"OpenBSD5\"
-DOSARCH=OpenBSD -DEXPORT_JS_API -DIMPL_MFBT -DJS_HAS_CTYPES
-DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so.1.0\" -DNO_NSPR_10_SUPPORT
-Ictypes/libffi/include -I.
I started updating the patch from comment #13 to hg tip, but so far on
sparc64 it fails with :
js/src/jscntxt.cpp: In member function 'void
js::ThreadData::sizeOfExcludingThis(size_t (*)(const void*, size_t), size_t*,
size_t*, size_t*, size_t*)':
js/src/jscntxt.cpp:163: error: invalid use of inc
Comment on attachment 588391
Use YARR interpreter instead of PCRE on platforms where YARR JIT is not
supported
I can confirm that this patch allows me to build & start firefox 10.0b4
on OpenBSD/powerpc... now, to see what to do for m-c.
--
You received this bug notification because you are a me
Just to clarify.. is your patch in debian a build fix for fx 10.0beta on
ppc & sparc, or only sparc ? currently 10.0b4 as is fails to build for
me on ppc, since it doesn't support yarr jit and !ENABLE_YARR_JIT is
not really maintained. I have a "simple" build fix, but i don't know yet
if it allows
Interested in this aswell for OpenBSD, i was planning to do an update to
our old spidermonkey 1.7.0 port from firefox 4 source tarball until i
saw that bug report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.
55 matches
Mail list logo
