net-libs/webkit-gtk doesn't play well for MIPS N32. 1. Platform.h refuses to build for N32 The Webkit doesn't treat MIPS N32 as the supported architure. Although the JIT won't work on MIPS N32, but disable it should be fine. 2. fastMalloc() is broken Just like IA64, fastMalloc() returns non-aligned address and causes crashing.
Created attachment 385582 [details, diff] Add MIPS N32 Platform
Created attachment 385584 [details, diff] Disable fastMalloc() for MIPS N32
The second patch is depends on webkit-gtk-2.4.1-ia64-malloc.patch, need tweak it.
Upstream don't care at all about mips... are this patches shared with any other distribution/people willing to keep webkit in a good shape there?
(In reply to Pacho Ramos from comment #4) > Upstream don't care at all about mips... are this patches shared with any > other distribution/people willing to keep webkit in a good shape there? This patch looks very unintrusive and is based on the IA64 fix. I should be easy to maintain and could be applied even uncondtionally (ie we don't need if use mips). The benefit would be we can finally compile apps depending on webkit-gtk. Before we add it, I'd like to know from Tom Li what plagtform he tested on? Was it the lemote yeeloong? And what apps he was able to build afterwards. I'll take responsibility for keeping that patch up if we do add it.
In that case nice :D But we need to know if that apps are buildable and really *work* (probably disabling "jit"). I think that is not the case for ia64 and probably others... but we would need to drop so many keywords :| (and, well, some apps like evolution-3.12 still "work" because it's not fully migrated to webkit yet...)
(In reply to Pacho Ramos from comment #6) > In that case nice :D > > But we need to know if that apps are buildable and really *work* (probably > disabling "jit"). I think that is not the case for ia64 and probably > others... but we would need to drop so many keywords :| (and, well, some > apps like evolution-3.12 still "work" because it's not fully migrated to > webkit yet...) Precisely, which is why I'd like to know the platform and what was tested. I will reproduce those tests at my end.
The patch looks small enough, so if you get the go from mips, I'm fine with it.
Can we enable N64 ABI support as well, so we can keyword ~mips without caveats?
I see no issues at all :) I was simply trying to ensure we won't need to drop it on the next version bump when people in mips starts to rely on webkit (in general, I tend to review patches from openBSD and Debian to try to follow a common pathway with them and, also, try to report a bug upstream (bugzilla.webkit.org) if none exists to, at least, let them know)
(In reply to Matt Turner from comment #9) > Can we enable N64 ABI support as well, so we can keyword ~mips without > caveats? (In reply to Tom Li from comment #1) > Created attachment 385582 [details, diff] [details, diff] > Add MIPS N32 Platform When I test I'll just change + && (defined(_ABIO32) || defined(_ABIN32)) to + && (defined(_ABIO32) || defined(_ABIN32) || defined(_ABIN64)) I'd still like to hear back from the original report Tom Li. What platform was used and what consumers of webkit-gtk were tested?
> I'd like to know the platform and what was tested. And what apps he was able to build afterwards. I tested on Lemote Yeeloong with Loongson 2F processor. After apply the patches, I can use ANY webkit-gtk based programs such as midori, yelp, uzbl, both GTK2 and GTK3 branches are working correctly. > try to report a bug upstream (bugzilla.webkit.org) if none exists to, at least, let them know https://bugs.webkit.org/show_bug.cgi?id=29954 It provided a similar hack for <Platform.h> and mentioned the crashing problem. But years passed, it is still no progress. I think there should be more bug reports, I read at least three bug reports when I try to make it works. Also, some Debian developers fixed some of the memory alignment issues on MIPS. But I can't find all of them now :( BTW, webkit is still buggy, if I compile the Linux kernel with 64KB instead of 16KB page size, webkit may crash. I read the git log, and it seems the previous patches in webkit was not a complete fix, and developers never test it on 64KB page size kernel. It is another problem and should discuss at the Webkit Bugzilla. > Upstream don't care at all about mips... Absolutely. > Can we enable N64 ABI support as well It may work. But I'll never use it. The ecosystem for MIPS N64 is terrible, many programs don't work properly. Before there is any tester, nobody knows if it actually works.
Thanks for all the work and testing :)
Created attachment 385818 [details, diff] debian-fix-mips-build.patch This is the only mips related patch I found in Debian
And this from openBSD: http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/webkit/patches/patch-Source_WTF_wtf_Platform_h http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/webkit/patches/patch-Source_WTF_wtf_dtoa_utils_h
I didn't get to clean those patches up. Note we have 2.2.6, 2.4.4 and 2.4.6. The original patches were for 2.4.3 and didn't apply cleanly. I didn't identify work out the equivalent for 2.4.4. (Running low on time due to real life!)
Hello, I have cleaned the patches and now the apply for webkit-gtk-2.4.6, and they work fine: # emerge -1Oq =net-libs/webkit-gtk-2.4.6 * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. >>> Verifying ebuild manifests >>> Running pre-merge checks for net-libs/webkit-gtk-2.4.6 >>> Emerging (1 of 1) net-libs/webkit-gtk-2.4.6::gentoo >>> Installing (1 of 1) net-libs/webkit-gtk-2.4.6::gentoo Patches attached in the two comments below.
Created attachment 386280 [details, diff] webkit-gtk-2.4.6-disable-fastMalloc-for-mips.patch
Created attachment 386282 [details, diff] webkit-gtk-2.4.6-add-mips64-support.patch
I have installed www-client/midori[webkit2] which consumes net-libs/webkit-gtk:3 and this is what happens when I try to run it: $ midori Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" The configuration couldn't be loaded: No such file or directory Bus error The last line is the one which is actually causing the problem. However, I have installed app-admin/packagekit-gtk and media-libs/libcanberra just in case. Then, when I try to run it again, I get the following: $ midori The configuration couldn't be loaded: No such file or directory Bus error Error receiving IPC message on socket -1 in process 31902: Bad file descriptor It seems the last line (the one about the IPC message on socket) it's only a log line which is not fatal, and the real problem stills being the "Bus error" line. And I think it's a webkit problem because I have tried to use the Javascript console provided by webkit and this is what happened: $ jsc-3 >>> "hello" Bus error
(In reply to Vicente Olivert Riera from comment #20) > Bus error This means unaligned access.
(In reply to Matt Turner from comment #21) > (In reply to Vicente Olivert Riera from comment #20) > > Bus error > > This means unaligned access. Why am I not surprised. Why isn't the kernel handling this? Poor alignment should be a perf hit, but not kill a process.
(In reply to Vicente Olivert Riera from comment #20) > > $ jsc-3 > >>> "hello" > Bus error Can you run this in gdb and get a backtrace so we can at least see what's causing the bus error.
> $ jsc-3 > >>> "hello" > Bus error This is the problem which is fixed by the patches, but...why?
(In reply to Anthony Basile from comment #22) > (In reply to Matt Turner from comment #21) > > (In reply to Vicente Olivert Riera from comment #20) > > > Bus error > > > > This means unaligned access. > > Why am I not surprised. Why isn't the kernel handling this? Poor alignment > should be a perf hit, but not kill a process. All address on MIPS must be aligned. Unaligned access could cause serious problem on MIPS, even kernel doesn't have chance to handle all of them in the current implementation. There was some patches to let kernel handle more unaligned access, but no one accept it.
(In reply to Anthony Basile from comment #23) > (In reply to Vicente Olivert Riera from comment #20) > > > > $ jsc-3 > > >>> "hello" > > Bus error > > Can you run this in gdb and get a backtrace so we can at least see what's > causing the bus error. # gdb jsc-3 GNU gdb (Gentoo 7.7 p1) 7.7 [...] Reading symbols from jsc-3...Reading symbols from /usr/lib/debug//usr/bin/jsc-3.debug...done. done. (gdb) run Starting program: /usr/bin/jsc-3 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib32/libthread_db.so.1". [New Thread 0x75cce470 (LWP 22999)] [New Thread 0x753aa470 (LWP 23000)] >>> "hello" Program received signal SIGBUS, Bus error. 0x77bf7ff4 in JSC::ExecutionCounter::deferIndefinitely() () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 (gdb) bt #0 0x77bf7ff4 in JSC::ExecutionCounter::deferIndefinitely() () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #1 0x77ca22f8 in llint_entry_osr () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #2 0x77cb0cb0 in JSC::LLInt::CLoop::execute(JSC::ExecState*, void*, bool) () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #3 0x77cb0354 in callToJavaScript () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #4 0x77ca0e08 in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*, JSC::Register*) () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #5 0x77c9c40c in JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #6 0x77d8c3a4 in JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) () from /usr/lib32/libjavascriptcoregtk-3.0.so.0 #7 0x10008cc4 in jscmain(int, char**) () #8 0x10004730 in main () (gdb)
Looks like the patches weren't really working no? :|
