Re: [webkit-dev] Problems building JavaScriptCore/WebKit for Windows desktop
There is nowhere to download just JavaScriptCore binaries on Windows, but I'll send you some off-list if you want. Depending on what you want to do with it, you'll probably want to build the WinCairo port because of the license on Apple's CoreFoundation libraries. You'll need to install everything on http://www.webkit.org/building/tools.html and build the Release_WinCairo configuration in WebKit.sln in Visual Studio 2013 to do this after running the update-webkit-wincairo-libs script. Feel free to contact me directly if you have any more questions. Alex Christensen On Tue, Apr 1, 2014 at 5:34 AM, Eric Wing wrote: > I am trying to build JavaScriptCore for Windows desktop. (Ultimately, > I just want a x86_64 .lib and .dll I can link against for Win 7 and 8. > I would be happy not building it and just downloading the pre-build > binaries somewhere if that's an option.) > > I've followed the instructions on the web page about building Webkit > and even looked to outside documentation, but I'm having tons of > problems. I've done multiple fresh installs of Windows 7 and 8.1 with > different versions of Visual Studio in VMs, but I'm not having any > luck. > > Among my various problems: > - The cygwin-downloader instructions about installing from the Local > Directory doesn't seem to work. When it is time to hit 'Next' in the > select the packages screen, it seems that the packages are not > detected. This results in nothing getting installed. My attempts to > force it to detect and install have failed. > - To workaround, I did the install the "default" way through the > internet. I manually went down the list selecting packages based on > the ones cygwin-downloader I see saved on my hard disk. > - The python version it picks by default is 2.7.x and Webkit > complains it needs 2.6.x so I have to force a downgrade. > - The curl or ssl package has some kind of bug and either requires > a > downgrade of one of the packages or a change to the > update-webkit-dependency script to use tlsv1 instead of sslv3 > - There is a missing instruction that C:\cygwin\bin must be added > to > the Windows %PATH%, otherwise a bunch of "/usr/bin/which bash" > commands fail (because it can't find bash) > - I get a warning about having svn 1.8.8 when 1.7.10 is the > supported one > - The php instructions to install php don't work. I think a link is broken. > - Running update-webkit causes me problems with Git (it just hangs) so > I went to the SVN source ball. > > - update-webkit reports after the SVN 1.8.8 warning with 2 instances > of "Error (2): The system cannot find the file specified." I don't > know what it's complaining about. It goes on to tell me I don't have > the Mozilla Math fonts. (I think those links may be stale.) But > finally it says "Installed tools are correct for the Webkit build" > > - I tried building using the build-jsc and build-webkit scripts and > also by opening the JavaScriptCore.sln directly in Visual Studio. > > I grabbed WebKit in 3 different some what random states. One was from > around July. One was maybe 4 months ago. And one was from Monday. > > Each one seemed to have a different problem and also looked for a > different Visual Studio version. This is what prompted me to install > all the different Visual Studio versions, with still no luck. > > Using the latest version (Monday) with Visual Studio 2013, I think > there are some new bugs in the code base. The build now expects Core > Foundation to be available on Windows to build WTF. This was not the > case before and I think this is a new bug. This propagates down to > SchedulePair.h which doesn't seem to have any non-Core Foundation > path. (I expect this will be a problem speaking from my Android work.) > > One of the prior versions was failing on ruby related stuff or could > not find files. I'm not fuzzy on the details because I've tried way > too many things. > > I would appreciate any advice/help in getting this built or just > getting a set of release binaries I can take and run. I don't need > bleeding edge stuff. I just want something that works. > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > -- Alex Christensen FlexSim Software Products, Inc. *1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097* *Voice: 801-224-6914 | Fax: 801-224-6984* *Email:* al...@flexsim.com *URL:* www.flexsim.com This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ___ webki
Re: [webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?
En 01/04/14 10:58, Sergio Villar Senin escribiu: > En 31/03/14 23:09, Benjamin Poulain escribiu: >> Hi, >> >> Now that EFL and GTK use CMake, can someone look at what is missing to >> enable the CSS JIT on Linux x86_64? >> >> Last time I tried, there were some issues with the headers. It is likely >> trivial to fix with a local build. >> >> I would be happy to fix any problem with the compiler if it does not >> work on Linux. > > Filed https://bugs.webkit.org/show_bug.cgi?id=131022 for WebkitGtk We finally reverted the patch enabling it as it was causing tons of crashes. I attached a backtrace to the bug. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Questions about JSC CLoop crashes on ppc64
cc’ing webkit dev because there may be other folks who might be interested in
this information, and/or may also be able to help.
On Apr 1, 2014, at 6:57 AM, Tomas Popela wrote:
> Hi Mark,
> if you don't mind I have some questions for you regarding to
> https://bugs.webkit.org/show_bug.cgi?id=128743 - CLoop crashes on PPC64,
> S390X as I'm lost in it.. While looking on it I came to
> https://bugs.webkit.org/show_bug.cgi?id=97586#c10 where you suggest to modify
> llint/LowLevelInterpreter.cpp and add there some debug prints. I tried it and
> I saw that t0.i32 != t0.i.. What that could mean?
>
> &t0.i32 = 0x3fffd709693c
> &t0.i = 0x3fffd7096938
> Setting t0.i = 0xfedcba9876543211;
> raw t0 = 0xfedcba9876543211
> Setting t0.i32 = 0x;
> raw t0 = 0xfedcba98
>
> Also another thing. I managed to compile trunk on that PPC64 machine. When I
> open jsc and just type "1" there it crashes as well. I have modified the
> *.asm files to print names of macros and labels to see the flow with:
>
> $ sed 's@^\(\..*\):$@&\ncloopDo // printf ("\1\\n");@'
> LowLevelInterpreter.asm
> $ sed 's@^macro \(.*\).*$@&\ncloopDo // printf ("\1\\n");@'
> LowLevelInterpreter.asm
>
FYI, there’s already some built-in tracing functionality for the C loop LLINT.
In LowLevelInterpreter.cpp, search for TRACE_OPCODE. You can define
ENABLE_TRACE_OPCODE 1 to enable that code. Similar to the tracing that you’ve
added, it will tell which opcodes are being executed but only at the opcode
granularity.
> and the same for LowLevelInterpreter64.asm as well. The flow is different
> between ppc64 and x86_64:
>
> [tpopela@ibm-power7r2-01 bin]$ ./jsc
> >>> 1
> &t0.i32 = 0x31982c2c
> &t0.i = 0x31982c28
> Setting t0.i = 0xfedcba9876543211;
> raw t0 = 0xfedcba9876543211
> Setting t0.i32 = 0x;
> raw t0 = 0xfedcba98
> doCallToJavaScript(makeCall)
> callToJavaScriptPrologue()
> checkStackPointerAlignment(tempReg, location)
> .stackHeightOK
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .copyArgs
> .copyArgsLoop
> Segmentation fault
>
> When I do this on my x86_64 machine the processflow is different.
>
> tpopela ~/dev/WebKit/WebKitBuild/Debug/bin > 14:24 [master]
> $ ./jsc
> >>> 1
> doCallToJavaScript(makeCall)
> callToJavaScriptPrologue()
> checkStackPointerAlignment(tempReg, location)
> .stackHeightOK
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .copyHeaderLoop
> .fillExtraArgsLoop <-
> .copyArgs
> .copyArgsLoop
> .copyArgsDone
> checkStackPointerAlignment(tempReg, location)
> makeJavaScriptCall(entry, temp)
> prologue(codeBlockGetter, codeBlockSetter, osrSlowPath, traceSlowPath)
> preserveCallerPCAndCFR()
> notFunctionCodeBlockGetter(targetRegister)
> notFunctionCodeBlockSetter(sourceRegister)
> moveStackPointerForCodeBlock(codeBlock, scratch)
> dispatch(advance)
> jumpToInstruction()
> traceExecution()
> checkStackPointerAlignment(tempReg, location)
> .opEnterDone
> callSlowPath(slowPath)
> prepareStateForCCall()
> cCall2(function, arg1, arg2)
> checkStackPointerAlignment(tempReg, location)
> restoreStateAfterCCall()
> dispatch(advance)
> jumpToInstruction()
> traceExecution()
> loadConstantOrVariable(index, value)
> .constant
> .done
> dispatch(advance)
> jumpToInstruction()
> traceExecution()
> loadConstantOrVariable(index, value)
> .constant
> .done
> dispatch(advance)
> jumpToInstruction()
> traceExecution()
> checkSwitchToJITForEpilogue()
> checkSwitchToJIT(increment, action)
> assertNotConstant(index)
> assert(assertion)
> doReturn()
> restoreCallerPCAndCFR()
> checkStackPointerAlignment(tempReg, location)
> .calleeFramePopped
> checkStackPointerAlignment(tempReg, location)
> callToJavaScriptEpilogue()
> 1
Looking at .fillExtraArgsLoop in LowLevelInterpreter64.asm, I see that it is
part of the loop that starts at .copyHeaderLoop.
I suggest you add some “cloopDo // printf(“…”);” tracing in the instructions
there and inspect the CLoopRegisters to see what values they contain to see why
the difference exists.
You can also add “cloopDo // myTestFunction();” and set a gdb breakpoint in
myTestFunction(). Thereafter, step thru the code to see how it works and
compare between x86_64 and ppc64.
> When it crashes on ppc64 it is crashing here:
>
> 106 pcBase.i64 = *CAST(t3.i8p + (pc.i << 3)); //
> /home/tpopela/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:225
> (gdb) p t3
> $1 = {{i = 0, u = 0, {i32padding = 0, i32 = 0}, {u32padding = 0, u32 = 0},
> {i8padding = "\000\000\000\000\000\000", i8 = 0 '\000'}, {u8padding =
> "\000\000\000\000\000\000", u8 = 0 '\000'}, ip = 0x0, i8p = 0x0, vp = 0x0,
> callFrame = 0x0, execState = 0x0, instruction = 0x0, vm = 0x0, cell = 0x0,
> protoCallFrame = 0x0, nativeFunc = 0x0, i64 = 0, u64 = 0, encodedJSValue = 0,
> castToDouble = 0, opcode = 0x0}}
>
> As you see the t3 register is completel
[webkit-dev] Problems building JavaScriptCore/WebKit for Windows desktop
I am trying to build JavaScriptCore for Windows desktop. (Ultimately, I just want a x86_64 .lib and .dll I can link against for Win 7 and 8. I would be happy not building it and just downloading the pre-build binaries somewhere if that's an option.) I've followed the instructions on the web page about building Webkit and even looked to outside documentation, but I'm having tons of problems. I've done multiple fresh installs of Windows 7 and 8.1 with different versions of Visual Studio in VMs, but I'm not having any luck. Among my various problems: - The cygwin-downloader instructions about installing from the Local Directory doesn't seem to work. When it is time to hit 'Next' in the select the packages screen, it seems that the packages are not detected. This results in nothing getting installed. My attempts to force it to detect and install have failed. - To workaround, I did the install the "default" way through the internet. I manually went down the list selecting packages based on the ones cygwin-downloader I see saved on my hard disk. - The python version it picks by default is 2.7.x and Webkit complains it needs 2.6.x so I have to force a downgrade. - The curl or ssl package has some kind of bug and either requires a downgrade of one of the packages or a change to the update-webkit-dependency script to use tlsv1 instead of sslv3 - There is a missing instruction that C:\cygwin\bin must be added to the Windows %PATH%, otherwise a bunch of "/usr/bin/which bash" commands fail (because it can't find bash) - I get a warning about having svn 1.8.8 when 1.7.10 is the supported one - The php instructions to install php don't work. I think a link is broken. - Running update-webkit causes me problems with Git (it just hangs) so I went to the SVN source ball. - update-webkit reports after the SVN 1.8.8 warning with 2 instances of "Error (2): The system cannot find the file specified." I don't know what it's complaining about. It goes on to tell me I don't have the Mozilla Math fonts. (I think those links may be stale.) But finally it says "Installed tools are correct for the Webkit build" - I tried building using the build-jsc and build-webkit scripts and also by opening the JavaScriptCore.sln directly in Visual Studio. I grabbed WebKit in 3 different some what random states. One was from around July. One was maybe 4 months ago. And one was from Monday. Each one seemed to have a different problem and also looked for a different Visual Studio version. This is what prompted me to install all the different Visual Studio versions, with still no luck. Using the latest version (Monday) with Visual Studio 2013, I think there are some new bugs in the code base. The build now expects Core Foundation to be available on Windows to build WTF. This was not the case before and I think this is a new bug. This propagates down to SchedulePair.h which doesn't seem to have any non-Core Foundation path. (I expect this will be a problem speaking from my Android work.) One of the prior versions was failing on ruby related stuff or could not find files. I'm not fuzzy on the details because I've tried way too many things. I would appreciate any advice/help in getting this built or just getting a set of release binaries I can take and run. I don't need bleeding edge stuff. I just want something that works. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?
En 31/03/14 23:09, Benjamin Poulain escribiu: > Hi, > > Now that EFL and GTK use CMake, can someone look at what is missing to > enable the CSS JIT on Linux x86_64? > > Last time I tried, there were some issues with the headers. It is likely > trivial to fix with a local build. > > I would be happy to fix any problem with the compiler if it does not > work on Linux. Filed https://bugs.webkit.org/show_bug.cgi?id=131022 for WebkitGtk BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
