Update the Mac OS X instructions on <http://www.webkit.org/building/debug.html> to explain how to debug Safari 5.1/WebKit 2. See <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process>.
Created attachment 105458 [details] Work-in-progress patch Work-in-progress patch I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. I am not so happy with this setup since it alternates between Xcode and the command line.
Created attachment 122285 [details] Patch
Created attachment 122286 [details] Screenshot of debug.html
Created attachment 122287 [details] Screenshot of debug-mac-uiprocess.html
Comment on attachment 122285 [details] Patch This seems OK to me. Certainly better than the very outdated instructions we have now.
Comment on attachment 122285 [details] Patch Clearing flags on attachment: 122285 Committed r105432: <http://trac.webkit.org/changeset/105432>
All reviewed patches have been landed. Closing bug.
(In reply to comment #1) > Created an attachment (id=105458) [details] > Work-in-progress patch > > Work-in-progress patch > > I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. > > I am not so happy with this setup since it alternates between Xcode and the command line. There is a more streamlined way to do this now that bug 75444 is fixed. You can have create a scheme whose executable is WebProcess and pass it the command-line options to launch the client (the UI process). The arguments look something like "$(BUILT_PRODUCTS_DIR)/WebKit2.framework/WebKit2" -type webprocess -client-executable /Applications/Safari.app/Contents/MacOS/Safari and the environment should contain DYLD_INSERT_LIBRARIES=$(BUILT_PRODUCTS_DIR)/WebProcessShim.dylib
(In reply to comment #8) > (In reply to comment #1) > > Created an attachment (id=105458) [details] [details] > > Work-in-progress patch > > > > Work-in-progress patch > > > > I took the "attach to WebProcess" instructions on <https://trac.webkit.org/wiki/Debugging%20the%20WebKit2%20Web%20Process> as inspiration for these updated instructions. In particular, I added WebProcess.app as the custom executable in the WebCore project and made Xcode wait for WebProcess.app to launch. Then ran run-safari to launch Safari. > > > > I am not so happy with this setup since it alternates between Xcode and the command line. > > There is a more streamlined way to do this now that bug 75444 is fixed. You can have create a scheme whose executable is WebProcess and pass it the command-line options to launch the client (the UI process). The arguments look something like > "$(BUILT_PRODUCTS_DIR)/WebKit2.framework/WebKit2" -type webprocess -client-executable /Applications/Safari.app/Contents/MacOS/Safari > and the environment should contain > DYLD_INSERT_LIBRARIES=$(BUILT_PRODUCTS_DIR)/WebProcessShim.dylib Sounds useful. Could we check in such a scheme into the repo?