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.

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

Fix merge conflicts after organization #12

Closed
wants to merge 40 commits into from
Closed

Fix merge conflicts after organization #12

wants to merge 40 commits into from

Conversation

RAJAGOPALAN-GANGADHARAN
Copy link

No description provided.

- Delete obsolete WorkQueue implementation (moved to WTF)
- Shuffle around includes list to get things working. Note that webcore
  forwarding headers are not used because there are a lot of files in
  the same dir and it confuses things (but other platforms do not seem
  to use that either)
- Fix some easy problems (FileSystem moved from WebCore to WTF, for
  example). ProcessExecutablePathHaiku is full of Linux-isms (trying to
  use /proc), so it should be replaced anyways.
- Enable some GTK/WPE stuff also for Haiku
- Skip over code needing DT_DIR and friends, as is done for Windows
Add a static_assert to make sure pid_t fits there.
Add conversion functions but I think they will not be needed (C integer
promotion will do the magic)
Match what is done in the curl version.
Add a static_assert to make sure pid_t fits there.
Add conversion functions but I think they will not be needed (C integer
promotion will do the magic)
@pulkomandy
Copy link
Member

Mh, not sure what you did, but it does not look right.
You should rebase or cherry-pick your extra commits (if any) on top of the current branch.

I spent some time cleaning up things, if you reintroduce all the previous commits that I cleaned up, my work is useless.

I fear that you are even reintroducing old code from the previous version of the webkit upstream code, which of course we don't want. And github tells me there are more than 3000 modified files so I can't review this.

@pulkomandy
Copy link
Member

Oh, and also you should submit merge requests to the webkit2 branch, not to rebased.
Until webkit2 is ready I'll keep rebased for maintenance of the existing webkitlegacy work. I'll add things there myself if I need them.

@RAJAGOPALAN-GANGADHARAN
Copy link
Author

When I wanted to merge the cleanup you did there were merge conflicts I discarded whatever was present in mine and took in the new one. 😢

@pulkomandy
Copy link
Member

Yes, you shouldn't merge, but rebase or cherry-pick instead.

@RAJAGOPALAN-GANGADHARAN
Copy link
Author

The changes were made in rebased branch? and I am supposed to cherry pick to webkit2?

@RAJAGOPALAN-GANGADHARAN
Copy link
Author

Now do I apply git reset to rollback changes ?

@pulkomandy
Copy link
Member

I have first merged things in "rebased", and then I moved the commits in "webkit2" on top of "rebased" and cleaned them up.

Looking at your "webkit2" branch, I see only a "fix merge conflict" commit that's different from the one in haiku/webkit. Did you have any other work in progress?

@RAJAGOPALAN-GANGADHARAN
Copy link
Author

I am only using webkit2 I don't use any other branches. But I seem to have all the latest fixes you have done and not any of the old code 😕

@pulkomandy
Copy link
Member

Ok then, but you have an extra commit that shouldn't be there.
Anyway, just create a merge request to haiku:webkit2 instead of haiku:rebased, we will see things better then

@leavengood
Copy link

Hi, I happen to get notified about PRs in this repo. I am pretty good with Git so wanted to comment.

It is pretty hard to lose things in Git, but rebasing or merging against the wrong thing can create quite a mess. Just calm down and step back a bit. I would first make another branch from your current branch as a backup of this current work. Then read about git reflog, and see about using that to get a hold of some of your missing commits:

https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog
https://git-scm.com/docs/git-reflog

If you rebase all you should see are your new commits on top of whatever branch you are rebasing against. If things don't look like that, something is wrong. I don't know exactly the state of this repo, or you fork, so I can't help as much in the details.

@RAJAGOPALAN-GANGADHARAN RAJAGOPALAN-GANGADHARAN changed the base branch from rebased to webkit2 May 8, 2019 19:23
@leavengood
Copy link

git rebase --interactive is also awesome to clean up a messed up Git history:

https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

You just have to make sure you only do this sort of thing on your own branches, NEVER on master, and preferably not on branches other people are working on with you.

@@ -99,6 +99,7 @@ WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_VIDEO_TRACK PUBLIC ON)
WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_WEB_AUDIO PUBLIC OFF)
WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_WEB_CRYPTO PUBLIC ON)
WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_XSLT PUBLIC ON)
WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_LEGACY_CUSTOM_PROTOCOL_MANAGER PUBLIC OFF)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here

@@ -89,7 +89,7 @@ class FrameLoaderClientHaiku : public FrameLoaderClient {
const AuthenticationChallenge&) override;

bool dispatchDidReceiveInvalidCertificate(DocumentLoader*,
const CertificateInfo& certificate, const char* message) override;
const CertificateInfo& certificate, const char* message);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here

@@ -46,8 +46,5 @@ int main(int argc, char** argv)
// WARNING: This needs to be KEPT IN SYNC with WebProcessMain.cpp.
setenv("G_TLS_GNUTLS_PRIORITY", "NORMAL:%COMPAT:!VERS-SSL3.0:!ARCFOUR-128", 0);

#if USE(GCRYPT)
PAL::GCrypt::initialize();
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here, I fixed this more cleanly by adding the missing #include

#include <pal/crypto/gcrypt/Initialization.h>
#endif
#endif*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should no be here

@@ -65,7 +65,7 @@ bool ArgumentCoder<ResourceResponse>::decodePlatformData(Decoder& decoder, Resou
return false;
resourceResponse.setSoupMessageFlags(static_cast<SoupMessageFlags>(soupMessageFlags));
return true;
*/
//
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here and will break the build (I used #if 0 instead of commenting out code)

PAL::GCrypt::initialize();
#endif
#endif*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here

#include <pal/crypto/gcrypt/Initialization.h>
#endif
#endif*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be here

pulkomandy pushed a commit that referenced this pull request Jan 12, 2020
…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
Labels
None yet
3 participants