[webkit-dev] precompiled headers
Hi, I'm working on a CMake based Windows port and have some problems with the precompiled headers. At the moment it's not possible to build the Windows port without them. Other ports don't require PCH. [1], [2] and [3] will make it work without PCH, but this patches raised up a general discussion about the PCH requirement. [4] says: The project should be able to build without this header, although we rarely test that. What does this mean? it should be possible to build the existing Mac and Windows ports without this prefix header, or it should be possible to construct a port that builds without this prefix header [5] says: ... This guarantees that each header's completeness is tested. This also assures that each header can be compiled without requiring any other header files be included first. Does header completeness include PCH? Should it be possible to build all ports without using precompiled headers? - Patrick [1] http://webkit.org/b/53881 [2] http://webkit.org/b/53883 [3] http://webkit.org/b/53885 [4] http://trac.webkit.org/browser/trunk/Source/WebCore/WebCorePrefix.h#L25 [5] http://webkit.org/coding/coding-style.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] coding style of #include statements
Currently, the style guidelines specify Includes of system headers must come after includes of other headers. But what about WebKit headers in arrow brackets? What is the correct style: #include ArgumentEncoder.h #include WorkItem.h #include wtf/HashSet.h #include wtf/OwnPtr.h #include QApplication #include QLocalServer or #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h I prefere the first one because wtf/*.h aren't real system headers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XMLHttpRequest memoryleak
Hi, I think WebKit (with JSC) leaks memory for every XMLHttpRequest and I need to fix this problem. Can somebody give me a hint where I should start? My testpage (http://paroga.com/webkit/memory.htm) only creates a request every second. Safari on windows leaks about 60KB/minute. QtBrowser on WinCE needs about 4KB/minute. I don't think that my values are correct, because of the garbage collector. Is there any easy way to dump a list of all used javascript objects (and references)? Can I trigger the GarbageCollecter manually to get the real memory usage? Maybe related bugs: https://bugs.webkit.org/show_bug.cgi?id=17534 https://bugs.webkit.org/show_bug.cgi?id=27041 - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XMLHttpRequest memoryleak
On Wed, 02 Jun 2010 10:07:59 -0700, Alexey Proskuryakov a...@webkit.org wrote: 02.06.2010, в 6:55, Patrick Roland Gansterer написал(а): I think WebKit (with JSC) leaks memory for every XMLHttpRequest and I need to fix this problem. Can somebody give me a hint where I should start? I don't think this has been fully investigated, but the current theory is that the memory is used by Safari Activity window, see https://bugs.webkit.org/show_bug.cgi?id=17534. How can I do further investigations? Where is the best point to start in the source code? I don't undersand why WebKit needs additional memory for every XMLHttpRequest. What is the memory used for? Mike Marchywka: I guess I would ask if you can empirically relate your test pages to a memory leak- can you say that simple html lacking javascript is leak free? Can you generally isolate the leak to JS? The leak occurs only when I use the XMLHttpRequest. E.g. a setTimeout seams to cost no memory. Can you or do you have any info on page faults? Safari.exe has about 300.000 page faults. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Hi,
The idea of a Options${PORT} file is to put only the port-specific
checks and defaults there.
When we now have a CMake buildsystem we can get rid of port-thinking. We
can switch to has-feature-thinking.
You should check for different features instead of doing sth for a spezial
port.
E.g. ICU is used in more than one port: If you check for ICU you only need
to define the ICU stuff once and the different ports can use it.
An other example is the win32 an wince port, where many files are shared:
You would create a port-file for win32 and wince then a general windows
port-file?.
Only one port file isn't applicable everywhere.
- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Hi, the file from Gustavo are mainly for the EFL port. It's not a general buildsystem and some parts are not real CMake style in the moment. I did some cleanup for the JavaScriptCore files already, but for the WebCore and WebKit parts it is a bigger task. As I already wrote at [1] I will help creating a general, not EFL specific, CMake buildsystem, but I didn't get any responses until now. - Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012599.html On Mon, 3 May 2010 15:23:11 -0400, Adam Treat tr...@kde.org wrote: Bill, could you look over these CMake files and give it an informal review? On Monday 03 May 2010 02:37:22 pm Gustavo Sverzut Barbieri wrote: Hi all, As some of you know, the EFL port is almost all merged, we just lack a build system in SVN by now. We initially started with automake, sharing with GTK, but it was quite slow and the Gtk guys had the willing to get it clean before any changes were made, in order to avoid it to get worse. We did an initial cleanup, but then we figured out CMake would be a better option. By the time we were almost done with CMake build system, this mail list started discussing build systems and CMake was one of the considered options, making us quite happy at the time. We got the system done, but then people just started to move files in SVN making our lives quite hard these last weeks. Fortunately things are calm now and the system compiles quite well. We did the patches splitting the common and EFL specific parts, so people may add new ports with minimum effort. Of course as more systems are added, we should rearrange things that we overlooked at first, but that should be easy. What we need know is someone to review https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. Note that we're trying to get EFL to build with SVN, not to build the most perfect CMake build system ever. So let's be reasonable with comments and suggestions, particularly those to make it generic as we consider that these should come when people start moving their ports to CMake. We surely can help with such tasks, we have a partially working GTK port that we may finish one day and suggest to webkit-gtk the move to it. BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Hi,
On Mon, 3 May 2010 17:33:45 -0300, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Did you see this new version? Leandro did the work on top of yours.
However he removed the .h from the source list, he did it before he
read that it may be useful to get some IDE to show it. If mandatory we
can add them back.
Yes, I've seen it. He did a great job, but there a some parts which are
not good for a general buildsystem.
E.g. INCLUDE(Options${PORT}) doesn't support different ports well, since
ports share some parts. (There some other points too; I'll post them on the
bug)
My vision is that the root CMake file will do all the WTF_USE_* stuff.
It has to decide all port specific stuff. All other CMake files should
only use this defines. This will provide a central to switch the
different implementations (e.g. switch between pthread and native threads
on windows).
I already run in some problem with my JavaScriptCore CMake files, but I
hoped for some feedback I didn't get.
My big question is if CMake should be added as a universal buildsystem (to
get rid of some other buildsystems) or if it is only for the EFL port?
I think this depends on ther progress in the CMake vs. GYP discussion. The
last post on the mailing list was [1].
- Patrick
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012662.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, 23 Apr 2010 00:54:02 -0700, Darin Fisher da...@chromium.org wrote: Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. Did you tried my CMake example for the JSC executable? You can find it at https://bugs.webkit.org/show_bug.cgi?id=37945. I think that it show the CMake VisualStudio integration very good: You can even compile one of the generator script (e.g. for the hashtables) and all files with dependencies will rebuild too. Maybe you can tell me what is missing in the generated vsproj, so I can look at it and improve the CMakeLists.txt? - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Wed, 21 Apr 2010 12:36:17 -0400, Marc-Antoine Ruel mar...@chromium.org wrote: Are the sources under an open source license? I'd like to take a look if so. I'm sorry, they are closed source. :-( But I have working CMake files for JSC on Windows already. I'd like to clean them up an try to get them run on other platform too before I post a patch at bugs.webkit.org. If you can't wait, I can send you my current files. You can see there for example how the the additional build steps like bison, hashtable generation, ... work. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CMake buildsystem for JSC
Hi, I created an example how the CMake files might look for WebKit. Since WebKit is a huge project I've done the task only for WTF, JavaScriptCore library and application. You can find this patch at https://bugs.webkit.org/show_bug.cgi?id=37945. If there is a real chance to use CMake as the main buildsystem (or at least get it into trunk) I will add the remaining projects (WebCore, DRT, ...) and improve it further. I only tried to build it on Win32 with CFLite and ICU. At the moment the CMakeLists.txt file in the root directory is hard coded for this port. A final version will detect the available platform features and create a cmakeconfig.h like the autotoolsconfig.h. The other CMakeLists.txt files are nearly finished. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
Hi, Gustavo Sverzut Barbieri: Find attached 2 patches. ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that implements CMake support for WebKit-EFL and also adds the missing patches to make it compile (but runs with some bugs, needs updating to some api changes). Apply it if you want to compile the port (also get EFL from svn, see http://svn.enlightenment.org/) ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single CMakeLists.txt and support *.cmake modules Please take a look if you are interested in CMake for WebKit-EFL. If you know CMake already, review it and send comments. My team just started with CMake some days ago. Can you please post the patch at bugs.webkit.org. Maybe you can split it into a CMake and a other stuff part. (Was it already before you merged it?) I'd like to give you some feedback at the bug comments. The CMake file should be split into different projects for example. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows mobile build
Hi, i had the same problem some months ago (https://lists.webkit.org/pipermail/webkit-dev/2010-January/011160.html), but didn't get any final reply. I had a look onto other (meta) buildsystems, but most of them lack WinCE (cross compile) support. I also tried gyp, but didn't get it working out of the box for WinCE. In my opinion qmake has the best support for building on WinCE at the moment. I also had the same idea like Kwang Yul. I think this (python) script should also generate all the other buildsystems (vcproj, xcode, GNUmake, qmake, ...). Then only this script must be changed when a file was added or removed. If I'm not wrong gyp was born to fulfil exactly this task? The best solution might be to add additional generators (e.g for the Qt-port) to gyp and then remove all other buildsystems from the tree? If somebody knows the long-term goal of the webkit buildsystem I'm very interested. If gyp is the preferred solution I might also spend some time with the WinCE part for it. - Patrick KwangYul, have you considered using gyp (and the files already there) rather than add another generating solution? Jason, have you considered using gyp to generate your solution? Disclaimer: I have no stake in gyp nor do I think it is necessarily better than anything else, but I do care about not modifying 7+ build files for any file additions/moves, etc. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
Hi, Can someone please decide how i should create a WinCE build system! Adam Roben: That sounds like a maintenance headache. Any new files will have to be added to both .vcproj files. Of course! The Apple and Cairo/libCURL ports of WebKit are already sharing .vcproj files. Can WinCE share these files, too? It is possible, but i'm not sure if it's the best solution: There will uncountable ExcludeFromBuild in the vcproj files and if we will add additional platforms i will grow further. If you add the STANDARDSDK_500 (ARMV4I) platform to the solution it might throw a warning if the SDK isn't installed. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ARM JIT for WinCE
Hi,
many thanks! It works already when I disable OPTIMIZE_NATIVE_CALL (other 3
OPTIMIZE are turned on). I think you're right with the ABI problem. Maybe you
can help me with it too: Here are the instruction dumps with and without the
OPTIMIZE_NATIVE_CALL:
==
== #define OPTIMIZE_NATIVE_CALL = 1 ==
==
003E0100 ldr r8, [r2, #8]
003E0104 cmp r8, #0
003E0108 bgt 003E012C
003E010C mov r7, lr
003E0110 mov r0, sp
003E0114 str r4, [sp, #0x40]
003E0118 mov lr, pc
003E011C ldr pc, [pc, #0x128]
003E0120 ldr r1, [sp, #0xC]
003E0124 mov lr, r7
003E0128 ldr r2, [r0, #0x18]
003E012C ldr r8, [r2, #8]
003E0130 cmp r8, r1
003E0134 beq 003E0160
003E0138 mov r7, lr
003E013C str r7, [sp, #8]
003E0140 mov r0, sp
003E0144 str r4, [sp, #0x40]
003E0148 mov lr, pc
003E014C ldr pc, [pc, #0x100]
003E0150 mov r4, r1
003E0154 ldr r1, [sp, #0xC]
003E0158 mov lr, r7
003E015C ldr r2, [r0, #0x18]
003E0160 str r1, [r4, #-0xC]
003E0164 ldr r1, [r0, #0x1C]
003E0168 ldr r8, [pc, #0xE8]
003E016C str r8, [r4, #-4]
003E0170 str r0, [r4, #-8]
003E0174 str r1, [r4, #-0x1C]
003E0178 ldr r0, [r2, #0xC]
003E017C mov pc, r0
003E0180 mov r0, lr
003E0184 str r0, [r4, #-0x14]
003E0188 ldr r1, [r4, #-0x18]
003E018C ldr r1, [r1, #-0x1C]
003E0190 str r1, [r4, #-0x1C]
003E0194 ldr r0, [r4, #-0xC]
003E0198 subssp, sp, #8
003E019C subsr0, r0, #1
003E01A0 str r0, [sp, #4]
003E01A4 mov r1, r4
003E01A8 subsr1, r1, #0x20
003E01AC mov r3, #4
003E01B0 mulsr0, r3, r0
003E01B4 subsr1, r1, r0
003E01B8 str r1, [sp]
003E01BC ldr r2, [r1, #-4]
003E01C0 ldr r1, [r4, #-8]
003E01C4 mov r0, r4
003E01C8 mov r3, sp
003E01CC mov lr, pc
003E01D0 ldr pc, [r1, #0x1C]
// R0 = 0x003f8080 R1 = 0x00601780 R2 = 0x00601760 R3 = 0x182af984
// R4 = 0x003f8080 R5 = 0x0200 R6 = 0x0060 R7 = 0x003e07b8
// R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
// R12 = 0x182af8f0 Sp = 0x182af984 Lr = 0x003e01d4
// Pc = 0x00073468 Psr = 0x201f
003E01D4 addssp, sp, #8
003E01D8 ldr r3, [pc, #0x7C]
003E01DC ldr r2, [r3]
003E01E0 bicsr3, r2, #0
003E01E4 bne 003E01F8
003E01E8 ldr r1, [r4, #-0x14]
003E01EC ldr r4, [r4, #-0x18]
003E01F0 mov lr, r1
003E01F4 mov pc, lr
003E01F8 ldr r1, [r4, #-0x14]
003E01FC ldr r2, [pc, #0x60]
003E0200 str r1, [r2]
003E0204 ldr r2, [pc, #0x5C]
003E0208 ldr r4, [r4, #-0x18]
003E020C str r4, [sp, #0x40]
003E0210 mov lr, r2
003E0214 mov pc, lr
==
JSValue JSC_HOST_CALL dateProtoFuncGetTimezoneOffset(ExecState* exec,
JSObject*, JSValue thisValue, const ArgList)
{
00073468 mov r12, sp
0007346C stmdb sp!, {r0 - r3}
00073470 stmdb sp!, {r4, r12, lr}
00073474 sub sp, sp, #0x1C
if (!thisValue.inherits(DateInstance::info))
00073478 ldr r1, [pc, #0x100]
// R0 = 0x003f8080 R1 = 0x00601780 R2 = 0x00601760 R3 = 0x182af984
// R4 = 0x003f8080 R5 = 0x0200 R6 = 0x0060 R7 = 0x003e07b8
// R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
// R12 = 0x182af984 Sp = 0x182af94c Lr = 0x003e01d4
// Pc = 0x00073478 Psr = 0x201f
0007347C add r0, sp, #0x34
00073480 bl |JSC::JSValue::inherits ( 6997ch )|
00073484 strbr0, [sp, #0xC]
00073488 ldrbr3, [sp, #0xC]
0007348C cmp r3, #0
00073490 bne |JSC::dateProtoFuncGetTimezoneOffset + 0x54 ( 734bch )|
return throwError(exec, TypeError);
00073494 mov r1, #5
00073498 ldr r0, exec
0007349C bl |JSC::throwError ( 5dd78h )|
000734A0 str r0, [sp, #0x10]
000734A4 ldr r1, [sp, #0x10]
000734A8 ldr r0, [sp, #0x28]
000734AC bl |
WTF::OwnArrayPtrJSC::Register::OwnArrayPtrJSC::Register ( 110e8h )|
000734B0 ldr r3, [sp, #0x28]
000734B4 str r3, [sp, #8]
000734B8 b |JSC::dateProtoFuncGetTimezoneOffset + 0x100 ( 73568h )|
DateInstance* thisDateObj = asDateInstance(thisValue);
000734BC ldr r0, thisValue
000734C0 bl |JSC::asRegExpConstructor ( 697b8h )|
000734C4 str r0, [sp,
Re: [webkit-dev] ARM JIT for WinCE
Hi,
I did some further investigation today.
I did a quick hack in the privateCompileCTIMachineTrampolines to get the same
maybe correct register values like without OPTIMIZE_NATIVE_CALL.
move(callFrameRegister, regT0);
+move(ARMRegisters::r2, ARMRegisters::r3);
+move(ARMRegisters::r1, ARMRegisters::r2);
+move(ARMRegisters::r0, ARMRegisters::r1);
-move(stackPointerRegister, ARMRegisters::r3);
+move(stackPointerRegister, ARMRegisters::r0);
-call(Address(regT1, OBJECT_OFFSETOF(JSFunction, m_data)));
+call(Address(regT2, OBJECT_OFFSETOF(JSFunction, m_data)));
addPtr(Imm32(sizeof(ArgList)), stackPointerRegister);
Now it produces the following code:
003E01B0 mulsr0, r3, r0
003E01B4 subsr1, r1, r0
003E01B8 str r1, [sp]
003E01BC ldr r2, [r1, #-4]
003E01C0 ldr r1, [r4, #-8]
003E01C4 mov r0, r4
003E01C8 mov r3, r2
003E01CC mov r2, r1
003E01D0 mov r1, r0
003E01D4 mov r0, sp
003E01D8 mov lr, pc
003E01DC ldr pc, [r2, #0x1C]
003E01E0 addssp, sp, #8
003E01E4 ldr r3, [pc, #0x80]
003E01E8 ldr r2, [r3]
003E01EC bicsr3, r2, #0
003E01F0 bne 003E0204
The arguments seam to be sane now in the call to
dateProtoFuncGetTimezoneOffset, but it crashes afterwards.
When i step through it with the debugger i get the following register after
the function finished and it jumps to 0x000139d8 instead of 0x003e01e0:
(lr = 0x003e01e0 when i enter the function!)
R0 = 0x182af984 R1 = 0x003f8054 R2 = 0x00601500 R3 = 0x0060
R4 = 0x003f8054 R5 = 0x0200 R6 = 0x182af984 R7 = 0x003f8054
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x182af8f0 Sp = 0x182af95c Lr = 0x003e01e0
Pc = 0x000139d8 Psr = 0x201f
I then tried to return jsNaN(exec) always. So R4 won't be used and
prolog/epilog changed:
00071600 mov r12, sp
00071604 stmdb sp!, {r0 - r3}
00071608 stmdb sp!, {r4, r12, lr}
0007160C sub sp, sp, #0x1C
00071700 ldr r0, [sp, #8]
00071704 add sp, sp, #0x1C
00071708 ldmia sp, {r4, sp, pc}
changed to
000734EC mov r12, sp
000734F0 stmdb sp!, {r0 - r3}
000734F4 stmdb sp!, {r12, lr}
000734F8 sub sp, sp, #0x1C
000735A4 ldr r0, [sp, #8]
000735A8 add sp, sp, #0x1C
000735AC ldmia sp, {sp, pc}
I now get following registers and it jumps to the correct address
(0x003e01e0), but it crashes then in functionPrint.
R0 = 0x182af984 R1 = 0x182af8f8 R2 = 0x R3 = 0x182af984
R4 = 0x003f8080 R5 = 0x0200 R6 = 0x0060 R7 = 0x003e07c8
R8 = 0x R9 = 0x182afbfc R10 = 0x R11 = 0x002b0370
R12 = 0x03fc2c50 Sp = 0x182af984 Lr = 0x0001bc18
Pc = 0x003e01e0 Psr = 0x601f
I tried jsc.exe with the following javascript file:
print(getTimeZoneDiff());
function getTimeZoneDiff() {
return (new Date(2000, 1, 1)).getTimezoneOffset();
}
This doesn't make many sense to me in the moment.
- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
David Kilzer: On Thu, December 24, 2009 at 1:51:43 AM, Patrick Roland Gansterer wrote: On Thu, Dec 24, 2009 at 02:53:18, Adam Barth: I'm worried that the port will rot without an active maintainer, no matter which build system you choose. If i choose my preferred solution, there will be many changes in the current sln/vcproj/vsprops files. Who is maintaining this files at the moment? I'd like to hear his/her opinion on this before. You can use svn/git log to see who commits changes to these files. I know Apple uses them for their Windows build, but we're on break until Jan 4, so please don't expect a reply until after that date. (I don't work on the Windows port much, so I don't have an opinion about your proposal.) Break is over and I didn't find a better working buildsystem for WincE than vcproj in the meantime. :-/ In the current trunk the vcproj files all use the Win32 defines. Because Win32 an WinCE have some parts in common i'd like to split the current vsprop files. To keep the vcproj files readable i prefer to add a second vcproj file for e.g. JavaScriptCore and a solution file with this new vcproj file. I'd like to start with the JavaScriptCore for STANDARDSDK_500 (ARMV4I). The last blocker for WinCE JavascriptCore is the missing TextCodec (see https://bugs.webkit.org/show_bug.cgi?id=32169) with a pending review request for a month. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ARM JIT for WinCE
Hi,
I'm trying to enable the JIT for CPU(ARM_TRADITIONAL) OS(WINCE).
It already passes the RegExp-Tests with ENABLE_YARR_JIT. If i set all
ENABLE_JIT_OPTIMIZE_* to 0 it won't compile.
MSVC supports inline assembler only for X86, so i had to provide a separate
asm file (i copied the code from the GCC #ifdef with !JSVALUE32_64):
ctiTrampoline proc
stmdb sp!, {r1-r3}
stmdb sp!, {r4-r8, lr}
sub sp, sp, #36
mov r4, r2
mov r5, #512
mov lr, pc
mov pc, r0
add sp, sp, #36
ldmia sp!, {r4-r8, lr}
add sp, sp, #12
mov pc, lr
endp
ctiVMThrowTrampoline proc
mov r0, sp
bl cti_vm_throw
endp
ctiOpThrowNotCaught proc
add sp, sp, #36
ldmia sp!, {r4-r8, lr}
add sp, sp, #12
mov pc, lr
endp
I can compile and link it without problems, but it crashes with a nullpointer
at runtime and a strange callstack. When i use a debugger and step into
ctiTrampoline it stops at the second stmdb because it can't find the
sourcecode. :-/
I've done a #pragma pack(4) around the JITStackFrame.
Can somebody give me a hint where to search for the failure?
- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
Adam Roben: That sounds like a maintenance headache. Any new files will have to be added to both .vcproj files. Of course! The Apple and Cairo/libCURL ports of WebKit are already sharing .vcproj files. Can WinCE share these files, too? It is possible, but i'm not sure if it's the best solution: There will uncountable ExcludeFromBuild in the vcproj files and if we will add additional platforms i will grow further. If you add the STANDARDSDK_500 (ARMV4I) platform to the solution it might throw a warning if the SDK isn't installed. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
Jason Rukman: We have a working wince build for all components right now including javascrtipcore, webcore and webkit COM layers. We'd like to help contribute this back in as well and work together with you on this. Can you give me a snapshot of your code or better publish it? When you use cairo (and curl for network?) it is only a cairo port. The qt port is working on WinCE too. During the last days i have begun finishing most of the work from Tourch Mobile. In my opinion the missing buildsystem is the biggest problem in the moment. I'm very interested in all of your WinCE work! If you can share your code i can also help with creating patches. Which WinCE SDK(s) do you use? - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
On Thu, Dec 24, 2009 at 02:53:18, Adam Barth: Please try to avoid this option if at all possible. The number of build systems in the tree is out of control already. Are there any plans to cleanup and use only one? I'm worried that the port will rot without an active maintainer, no matter which build system you choose. If i choose my preferred solution, there will be many changes in the current sln/vcproj/vsprops files. Who is maintaining this files at the moment? I'd like to hear his/her opinion on this before. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] build system for wince port
Currently the Windows CE port has no working build system. I'd like to contribute one, but i need to know the preferred solution: (1) Add the port to the current sln/vsproj/vsprops files a) Extend the sln/vsproj with the additional platforms and add many FileConfiguration ExcludedFromBuild=true and split the vspops. b) Add a separate main vsproj file (JavaScriptCore.vcproj, WebCore.vcproj) for the port (like code.staikos.net) c) Split the current main vspoj files into a platform dependent and independent file (2) Add it to a other build system like gyp or bkl. Which one provides good cross compiling features for wince? (3) Add a completely independent build system Which one is the least ugly one? I prefer 1a in the moment. I'd like to start with STANDARDSDK_500 (ARMV4I) and then add other supported STANDARDSDK_500 platforms. Because the wince port isn't finished right now, it's only possible to provide it for WTF and JavaScriptCore (including tests). Is already anything in the repository with support for cross compiling (something like Scripts/build-webkit)? Is anybody _active_ working on the wince port? Most of the related bugs are inactive for months now. Does anybody have the last git repository form git://code.staikos.net/WebKit- CE before it has gone offline? (my last log message is from 2009-07-30) I'd like to do some additional work in porting the remaining parts, when i have a working build system for it. - Patick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Partial SVG repaint
SVG was designed to support this, it's just not been turned on yet. Can you please show me how i can turn it on. ;-) Currently i set a attribute in the SVG at ... http://trac.webkit.org/browser/trunk/WebCore/svg/SVGRectElement.cpp#L101 .. this will shedule a layout via .. http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderObject.h#L882 http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderObject.h#L976 http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderObject.cpp#L2017 http://trac.webkit.org/browser/trunk/WebCore/page/FrameView.cpp#L1062 http://trac.webkit.org/browser/trunk/WebCore/page/FrameView.cpp#L985 http://trac.webkit.org/browser/trunk/WebCore/page/FrameView.cpp#L624 http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderSVGRoot.cpp#L102 ... http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderObject.cpp#L1166 ... where the oldBounds and newBounds contain the coorect coordinates (at least for simple rects :). But the damageRect is the whole frame size in http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderLayer.cpp#L2038 I use the Qt-Port. Maybe the dirtyRegion is only wrong there, but i don't think so because e.g. Safari shows the same performance problem. I'm not sure I would suggest such a change as your first change to WebKit though. It could have lots of fallout. :) I have a big perfromance problem with my dynamic SVG. So the only alternative is, that i create my own SVG renderer, which is not a real option. Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Partial SVG repaint
I want to fix https://bugs.webkit.org/show_bug.cgi?id=30055. What is the prefered solution? Where is the best place to start? If i start the work i might ends up in one big patch. So what are the code areas i can create single patches from? Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
