Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ipc iteration3 #16

Merged
merged 6 commits into from
Jun 7, 2019
Merged

Ipc iteration3 #16

merged 6 commits into from
Jun 7, 2019

Conversation

RAJAGOPALAN-GANGADHARAN
Copy link

No description provided.

@RAJAGOPALAN-GANGADHARAN
Message Listener attached to Workqueue thread first iteration
09c34e3 
1)Added a message stashing feature so it stashes the messages and interprets them when the loop is ready to run
2)Now have to fix connection between network and webprocess
@RAJAGOPALAN-GANGADHARAN
Fixed the worqueue ambiguity
8ac4b29 
This time used maps to store loopers and BApplications to forward message to appropriate loopers
@RAJAGOPALAN-GANGADHARAN
IPC communication WIP
6bf81d7 
1) Created a message from ui process to network process that notifies the pid of webprocess
2) Successfully created networkconnectionToWebProcess
3) Replying back to webProcess is not working(to be fixed - i should probably take help from webkit people as im pretty lost)
@RAJAGOPALAN-GANGADHARAN
Tried the new Adding messenger technique (relies only once on the mai…
0db6fbd 
…n loop for handshaking)
@RAJAGOPALAN-GANGADHARAN
Finalizing IPC communication related things
300d585 
1) Added NetworkSession so it doesnt crash
2) Added missing run loop getter
@RAJAGOPALAN-GANGADHARAN
Enable logging with BeDC
c936881
@pulkomandy pulkomandy merged commit b0841fb into haiku:webkit2 Jun 7, 2019
@RAJAGOPALAN-GANGADHARAN RAJAGOPALAN-GANGADHARAN deleted the ipc-iteration3 branch June 29, 2019 19:13
pulkomandy pushed a commit that referenced this pull request Dec 30, 2019
[JSC] Extend MacroAssemblerARM64::load/store for datasize = 16
30ba860 
https://bugs.webkit.org/show_bug.cgi?id=204442
<rdar://problem/57366761>

Reviewed by Mark Lam.

Our `void load16(const void* address, RegisterID dest)` and `void store16(RegisterID src, const void* address)` are not aware of
the condition that passed register can be memoryTempRegister, while `MacroAssemblerARM64::{load,store}` handles it correctly, e.g.
`load` invalidates `cachedMemoryTempRegister` if destination register is memoryTempRegister. As a result, when we are emitting
`or16(TrustedImm32 imm, AbsoluteAddress address)` with address where the address's value does not fit in imm, the generated code
is reusing memoryTempRegister incorrectly.

    0xedf8d4fb4: mov    x17, #0x7af0
    0xedf8d4fb8: movk   x17, #0xd5a, lsl #16
    0xedf8d4fbc: movk   x17, #0x1, lsl #32        // Construct imm register on x17.
    0xedf8d4fc0: ldrh   w17, [x17]                // Load half word from x17 to w17 (we should invalidate x17 memoryTempRegister here).
    0xedf8d4fc4: mov    w16, #0x1b
    0xedf8d4fc8: orr    w16, w17, w16
    0xedf8d4fcc: strh   w16, [x17]                // x17 memoryTempRegister is reused while its content is invalid.

The problem is that `load` and `store` functions are not supporting datasize = 16 case. This patch extends `MacroAssemblerARM64::{load,store}`
to support 16 so that `or16` implementation looks is similar to `or32` etc.

* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16):
(JSC::MacroAssemblerARM64::store16):
(JSC::MacroAssemblerARM64::load):
(JSC::MacroAssemblerARM64::store):
* assembler/testmasm.cpp:
(JSC::testOrImmMem):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@252728 268f45cc-cd09-0410-ab3c-d52691b4dbfc
pulkomandy pushed a commit that referenced this pull request Jan 12, 2020
Fix the x86_64 probe so that we can get a full stack trace with libun…
2db0880 
…wind and lldb.

https://bugs.webkit.org/show_bug.cgi?id=205050

Reviewed by Michael Saboff.

Before this patch, the stack trace from inside a probe function is cut off at ctiMasmProbeTrampoline:

    (lldb) bt
    * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
        ...
        frame #4: 0x0000000100824607 JavaScriptCore`WTF::Function<void (JSC::Probe::Context&)>::operator(this=0x000000010b88bd00, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35
        frame #5: 0x0000000100823996 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5
        frame #6: 0x000000010082701e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5
        frame #7: 0x000000010082614b JavaScriptCore`ctiMasmProbeTrampoline + 299
    (lldb) 

After this patch, we'll now get the full stack trace from inside the probe function:

    (lldb) bt
    * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
        ...
        frame #4: 0x0000000100826d17 JavaScriptCore`WTF::Function<void (JSC::Probe::Context&)>::operator(this=0x0000000106b878f8, in=0x00007ffeefbfd400)(JSC::Probe::Context&) const at Function.h:79:35
        frame #5: 0x0000000100826106 JavaScriptCore`JSC::stdFunctionCallback(context=0x00007ffeefbfd400) at MacroAssembler.cpp:53:5
        frame #6: 0x000000010082986e JavaScriptCore`JSC::Probe::executeProbe(state=0x00007ffeefbfd480) at ProbeContext.cpp:51:5
        frame #7: 0x00000001008289a2 JavaScriptCore`ctiMasmProbeTrampoline + 338
        frame #8: 0x0000466db28025be
        frame #9: 0x0000000100754ffc JavaScriptCore`llint_entry at LowLevelInterpreter.asm:994
        frame #10: 0x0000000100738173 JavaScriptCore`vmEntryToJavaScript at LowLevelInterpreter64.asm:307
        frame #11: 0x0000000101489307 JavaScriptCore`JSC::JITCode::execute(this=0x0000000106ba1520, vm=0x0000000106d00000, protoCallFrame=0x00007ffeefbfd9b8) at JITCodeInlines.h:38:38
        frame #12: 0x0000000101488982 JavaScriptCore`JSC::Interpreter::executeProgram(this=0x0000000106bfd1f8, source=0x00007ffeefbff090, (null)=0x000000010d0e0000, thisObj=0x000000010d0e8020) at Interpreter.cpp:847:51
        frame #13: 0x00000001017d1f9c JavaScriptCore`JSC::evaluate(globalObject=0x000000010d0e0000, source=0x00007ffeefbff090, thisValue=JSValue @ 0x00007ffeefbfef60, returnedException=0x00007ffeefbff0b0) at Completion.cpp:146:38
        frame #14: 0x000000010005838f jsc`runWithOptions(globalObject=0x000000010d0e0000, options=0x00007ffeefbff620, success=0x00007ffeefbff48b) at jsc.cpp:2670:35
        frame #15: 0x000000010002a0da jsc`jscmain(this=0x00007ffeefbff5a0, vm=0x0000000106d00000, globalObject=0x000000010d0e0000, success=0x00007ffeefbff48b)::$_6::operator()(JSC::VM&, GlobalObject*, bool&) const at jsc.cpp:3157:13
        frame #16: 0x0000000100006eff jsc`int runJSC<jscmain(int, char**)::$_6>(options=0x00007ffeefbff620, isWorker=false, func=0x00007ffeefbff5a0)::$_6 const&) at jsc.cpp:3003:9
        frame #17: 0x0000000100005988 jsc`jscmain(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:3150:18
        frame #18: 0x000000010000575e jsc`main(argc=10, argv=0x00007ffeefbff6c8) at jsc.cpp:2498:15
        frame #19: 0x00007fff6cfc4da9 libdyld.dylib`start + 1
        frame #20: 0x00007fff6cfc4da9 libdyld.dylib`start + 1
    (lldb)

The difference is that the x86_64 ctiMasmProbeTrampoline now uses the standard
function prologue, and keeps %rbp pointing to trampoline function's semblance of
a frame that libunwind can understand while it calls the probe function.

* assembler/MacroAssemblerX86Common.cpp:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@253320 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
2 participants
@RAJAGOPALAN-GANGADHARAN @pulkomandy