date:20100107

Re: [webkit-dev] ARM JIT for WinCE

2010-01-07 Thread Zoltan Herczeg

Hi Patrick,

hm, I feel I found something. Please have a look at
JavaScriptCore/jit/JITOpcodes.cpp : privateCompileCTIMachineTrampolines.
The second one, when JSVALUE32_64 is disabled. If JIT_OPTIMIZE_NATIVE_CALL
is enabled, a specialized code is generated to call native builtin
functions (like Date.toString). This code for arm is around line 1733.
Perhaps WinCE ABI wants the arguments in a different way than GCC. The
faulting address according to your call stack is 0x003e01d4, which is the
call(Address(regT1, OBJECT_OFFSETOF(JSFunction, m_data))); macro
assembler instruction in line 1768. (Thank you for sending the instruction
dump). Please try to fix this code according to WinCE ABI, since I am not
sure JIT_OPTIMIZE_NATIVE_CALL can be disabled.

Regards
Zoltan

 Hi Gabor,

 Thanks for your prompt reply.

 Make sure your assembler does not break ctiVMThrowTrampoline
 and ctiOpThrowNotCaught functions. This approach requires that the
 ctiVMThrowTrampoline fall-backs to ctiOpThrowNotCaught
 after 'bl cti_vm_throw' call. Or you can simply copy the body of
 ctiOpThrowNotCaught into ctiVMThrowTrampoline after the
 call.
 I've copied it, but I think it's unnecessary (see disassembly)

 Did you do anything with DEFINE_STUB_FUNCTION macro?
 I've done it like for the RVCT compiler. (e.g. see cti_op_end in
 disassembly)

 When I run jsc.exe tests\mozilla\ecma_2\shell.js it crashes with the
 following callstack:
 0x
 jsc.EXE!JSC::JSCell::inherits(JSC::ClassInfo* info = 0x00189818) Line:
 335,
 Byte Offsets: 0x2c
 jsc.EXE!JSC::JSValue::inherits(JSC::ClassInfo* classInfo = 0x00189818)
 Line:
 345, Byte Offsets: 0x40
 jsc.EXE!JSC::dateProtoFuncGetTimezoneOffset(JSC::ExecState* exec =
 0x00601b60,
 JSC::JSObject* __formal = 0x00601b40, JSC::JSValue thisValue = {...},
 JSC::ArgList __formal = {...}) Line: 764, Byte Offsets: 0x1c
 0x003e01d4

 Is there a better javascript file to start with? When I enter a simple
 1+2+3
 into the interactive jsc.exe it prints the correct result.

 Here are some parts of the disassembly:

 // Execute the code!
 inline JSValue execute(RegisterFile* registerFile, CallFrame*
 callFrame, JSGlobalData* globalData, JSValue* exception)
 {
 000A7868  mov r12, sp
 000A786C  stmdb   sp!, {r0 - r3}
 000A7870  stmdb   sp!, {r12, lr}
 000A7874  sub sp, sp, #0x20
 return
 JSValue::decode(ctiTrampoline(m_ref.m_code.executableAddress(),
 registerFile,
 callFrame, exception, Profiler::enabledProfilerReference(), globalData));
 000A7878  bl  |JSC::Profiler::enabledProfilerReference ( 1b2e0h )|
 000A787C  str r0, [sp, #0x14]
 000A7880  ldr r0, this
 000A7884  bl  |WTF::RefPtrJSC::Profile::operator- ( d2e3ch )|
 000A7888  str r0, [sp, #0x18]
 000A788C  ldr r3, globalData
 000A7890  str r3, [sp, #4]
 000A7894  ldr r3, [sp, #0x14]
 000A7898  str r3, [sp]
 000A789C  ldr r3, exception
 000A78A0  ldr r2, callFrame
 000A78A4  ldr r1, registerFile
 000A78A8  ldr r0, [sp, #0x18]
 000A78AC  bl  0014A000
 000A78B0  str r0, [sp, #0x1C]
 000A78B4  ldr r1, [sp, #0x1C]
 000A78B8  ldr r0, [sp, #0x2C]
 000A78BC  bl  |JSC::JSValue::decode ( 1b94ch )|
 000A78C0  ldr r3, [sp, #0x2C]
 000A78C4  str r3, [sp, #0x10]
 }
 000A78C8  ldr r0, [sp, #0x10]
 000A78CC  add sp, sp, #0x20
 000A78D0  ldmia   sp, {sp, pc}

 

 ctiTrampoline:
 0014A000  stmdb   sp!, {r1 - r3}
 0014A004  stmdb   sp!, {r4 - r8, lr}
 0014A008  sub sp, sp, #0x24
 0014A00C  mov r4, r2
 0014A010  mov r5, #2, 24
 0014A014  mov lr, pc
 0014A018  bx  r0// r0 = 0x003e0270
 0014A01C  add sp, sp, #0x24
 0014A020  ldmia   sp!, {r4 - r8, lr}
 0014A024  add sp, sp, #0xC
 0014A028  bx  lr
 ctiVMThrowTrampoline:
 0014A02C  mov r0, sp
 0014A030  bl  0014A6D4
 0014A034  add sp, sp, #0x24
 0014A038  ldmia   sp!, {r4 - r8, lr}
 0014A03C  add sp, sp, #0xC
 0014A040  bx  lr
 ctiOpThrowNotCaught:
 0014A044  add sp, sp, #0x24
 0014A048  ldmia   sp!, {r4 - r8, lr}
 0014A04C  add sp, sp, #0xC
 0014A050  bx  lr
 cti_op_convert_this:
 0014A054  str lr, [sp, #0x20]
 0014A058  bl  |JITStubThunked_op_convert_this ( ae718h )|
 0014A05C  ldr lr, [sp, #0x20]
 0014A060  bx  lr
 cti_op_end:
 0014A064  str lr, [sp, #0x20]
 0014A068  bl  |JITStubThunked_op_end ( ae878h )|
 0014A06C  ldr lr, [sp, #0x20]
 0014A070  bx  lr

 

 003E017C  mov pc, r0
 003E0180  mov r0, lr
 003E0184  str r0, [r4, #-0x14]
 003E0188  ldr r1, [r4,

[webkit-dev] webkit-patch

2010-01-07 Thread Adam Barth

In the wee hours of the morning, I renamed bugzilla-tool to
webkit-patch to reflect the tool's general purpose of helping
contributors manage their patches.  I also renamed a bunch of the
common commands to make more sense with this name.  Here's a brief
summary of my three favorite commands:

* webkit-patch upload

This command automates the process of uploading a patch for review.
After you're done writing the code, the command will create a bug for
you (or let you pick an existing bug), prepare a ChangeLog, let you
edit the ChangeLog, and then upload the patch to the bug and mark it
for review.

* webkit-patch land

This command will help you land a patch that's been reviewed.  The
command will fill in the reviewer from the bug, build WebKit, and run
the LayoutTests.  If the tests pass, the command will land your patch.

* webkit-patch land-from-bug

This command does everything that land does except it downloads the
reviewed patch from the bug and applies it to your working copy first.
 If the bug has more than one patch, it will land all the reviewed
patches in the order they appear in the bug.

You can find out about these and other commands by running
webkit-patch --help.  If you'd like more details about a command
(e.g., land), run webkit-patch help land.

These commands still need some amount of polish, especially upload,
which is the newest.  If you have suggestions for improving
webkit-patch, please let me, Eric Seidel, or David Kilzer know.

Happy patching!
Adam
___
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

2010-01-07 Thread Patrick Roland Gansterer

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,

[webkit-dev] Accept Header and application/xml

2010-01-07 Thread Tobias Tom

Hello,

While developing our web-application framework we implemented content
negotiation, based on the accept header. In all webkit based browsers in my
tests (Safari, Chrome) the accept header was the same, so I assume it's right
to ask the question here. If it's not please forgive me and give me a hint into
the right direction.

The default accept header of webkit seems to be
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Which has as a result that content of the type application/xml and xhtml+xml
are the most preferred ones.

Is there any reason why text/html has a lower quality then application/xml? I
can understand the fact that xhtml should be preferred before html, but Webkit
itself is not able to render application/xml in a human format anyway (no
offense here, I think that's really ok). It is able to render text/html.

My real-life problem here is the following: A resource is available inside an
(machine-optmized) XML format and in (human optimized) HTML format under the
same URL. Webkit will always get the XML version. Is there any reason for that?

From what I understand, removing the application/xml header seems to most
reasonable solution. Currently I cannot see any sense in this value because,
as mentioned above, webkit isn't even able to render it for humans.
Even if it could, e.g. like Gecko, shouldn't html be the format of choice for
humans?

Thank you very much for your comments.
Tobias
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

38 matches

Mail list logo