[webkit-dev] Postmortum on webkit bug 71122
I just finished fixing http://crbug.com/75604 aka https://bugs.webkit.org/show_bug.cgi?id=71122 , and it was a long process, and pretty involved, and had a lot of cycles of change, wait for crash data, etc... So here's my postmortum: TL;DR No matter how sure you are you fixed a crashing bug, keep reading crash reports to be sure. TL;DR2 Practice release crash dump debugging regularly. Read dissassembled code and never trust symbols. TL;DR3 When in doubt, add more state to enhance crash dumps. TL;DR4 WebKit can save stacks in memory now. gav...@webkit.org can help you use this. WHAT WAS HAPPENING The ScriptRunner was crashing, and we were getting a lot of uploads. We couldn't reproduce it by going to the same URIs, but it was definitely happening a lot in the wild. It didn't seem like other WebKit ports were seeing this bug either, which was interesting. WHAT WE DID 1. The crash in ScriptRunner was happening in ScriptRunner::timerFired(), and it looked like a CachedScript in the list of runnable scripts was NULL. How did that happen? So I added a CRASH() to ScriptRunner::queueScriptForExecution(). This meant we would crash before setting up the Async event, and maybe get a more interesting stack on our crash dumps? https://bugs.webkit.org/show_bug.cgi?id=65563 2. From this, we learned a few things. Crash dumps told us we definitely had a broken ScriptElement, and every stack showed a network error was in progress. The CachedScript in the ScriptElement was bad, and we couldn't figure out why. So, we added a hidden state machine to ScriptElement to track down how it was being zeroed. Was it double notification, or was the load continuing after being stopped? Crash dumps would tell. https://bugs.webkit.org/show_bug.cgi?id=66939 3. It was double notification. Nobody could figure out how on earth double notification happened. Boy, I'd sure like to know the stack at the time of the first ScriptElement::notifyFinished() call... So we added a new stack saving facility to WebKit, and used it here to save a stack inside the ScriptElement on every call to ScriptElement::notifyFinished(). Mosquito, meet our sledgehammer. https://bugs.webkit.org/show_bug.cgi?id=69453 4. Oh, so the earlier stack was data received, but with a response code = 400? How interesting... Finally I could reproduce the bug, and introduce a fix. https://bugs.webkit.org/show_bug.cgi?id=71122 WHAT WORKED 1. Windows minidumps. In Chrome, our dev and canary channels have enabled a very useful option that gives you some heap. In walking the stack on Windows when crashing, any stack element interpretable as a pointer gets the 1024byte range [p-256,p+768] saved into the dump. This feature makes debugging from dev or canary windows minidumps superior to anything else. Learn how to use windb(a)g. 2. Progressive instrumentation. As usual, once I had a reproduction a fix was pretty easy. But, while I didn't have a reproduction, it was useful to add release assertions and watch crash dumps, to progressively zone in on this bug. 3. Adding new facilities to WebKit. You want stacks saved in memory on every platform? OK. https://bugs.webkit.org/show_bug.cgi?id=69018 WHAT DIDN'T WORK 1. Debuggers. Hackers who should have known better looked at release minidumps and symbols, and couldn't understand the variables. For a good example of this mistake from me, see http://code.google.com/p/chromium/issues/detail?id=75604#c21 . Want to see someone even smarter make the same mistake? http://code.google.com/p/chromium/issues/detail?id=75604#c43 The ScriptElement wasn't bogus, but the symbols data was. The symbols indicated ECX had this, when this was actually in EAX at the time, or [ESP]. Don't trust symbols in release builds; instead dissassemble the function, and figure out where the data is. The symbols probably said ECX because at the point of first dereference or maybe at call time, in that scope, this was probably in ECX. But in optimised code, that doesn't have much to do with anything anywhere else in the code. Read the dissassembly. 2. Reading code. I spent far, far too much time doing this. You know what, usually this works for me: I read code, consider the stack, have an AHA! moment, and fix my bug. Too bad this bug was beyond my cognitive horizon, and reading code was just a great way to waste time. 3. Not watching crashes. See comments 30 and 31 in the bug: http://code.google.com/p/chromium/issues/detail?id=75604#c30 . We should not have had confidence the problem was solved; since, hey, it wasn't. SPECIAL THANKS TO a...@webkit.org for encouraging me to instrument where it helps. cbent...@chromium.org for putting up with my yak shaving. ero...@chromium.org for showing me how to use windb(a)g. jap...@chromium.org for never giving up hope. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Postmortum on webkit bug 71122
[resend with nicer formatting] I just finished fixing http://crbug.com/75604 aka https://bugs.webkit.org/show_bug.cgi?id=71122 , and it was a long process, and pretty involved, and had a lot of cycles of change, wait for crash data, etc... So here's my postmortum: TL;DR No matter how sure you are you fixed a crashing bug, keep reading crash reports to be sure. TL;DR2 Practice release crash dump debugging regularly. Read dissassembled code and never trust symbols. TL;DR3 When in doubt, add more state to enhance crash dumps. TL;DR4 WebKit can save stacks in memory now. gav...@webkit.org can help you use this. WHAT WAS HAPPENING The ScriptRunner was crashing, and we were getting a lot of uploads. We couldn't reproduce it by going to the same URIs, but it was definitely happening a lot in the wild. It didn't seem like other WebKit ports were seeing this bug either, which was interesting. WHAT WE DID 1. The crash in ScriptRunner was happening in ScriptRunner::timerFired(), and it looked like a CachedScript in the list of runnable scripts was NULL. How did that happen? So I added a CRASH() to ScriptRunner::queueScriptForExecution(). This meant we would crash before setting up the Async event, and maybe get a more interesting stack on our crash dumps? https://bugs.webkit.org/show_bug.cgi?id=65563 2. From this, we learned a few things. Crash dumps told us we definitely had a broken ScriptElement, and every stack showed a network error was in progress. The CachedScript in the ScriptElement was bad, and we couldn't figure out why. So, we added a hidden state machine to ScriptElement to track down how it was being zeroed. Was it double notification, or was the load continuing after being stopped? Crash dumps would tell. https://bugs.webkit.org/show_bug.cgi?id=66939 3. It was double notification. Nobody could figure out how on earth double notification happened. Boy, I'd sure like to know the stack at the time of the first ScriptElement::notifyFinished() call... So we added a new stack saving facility to WebKit, and used it here to save a stack inside the ScriptElement on every call to ScriptElement::notifyFinished(). Mosquito, meet our sledgehammer. https://bugs.webkit.org/show_bug.cgi?id=69453 4. Oh, so the earlier stack was data received, but with a response code = 400? How interesting... Finally I could reproduce the bug, and introduce a fix. https://bugs.webkit.org/show_bug.cgi?id=71122 WHAT WORKED 1. Windows minidumps. In Chrome, our dev and canary channels have enabled a very useful option that gives you some heap. In walking the stack on Windows when crashing, any stack element interpretable as a pointer gets the 1024byte range [p-256,p+768] saved into the dump. This feature makes debugging from dev or canary windows minidumps superior to anything else. Learn how to use windb(a)g. 2. Progressive instrumentation. As usual, once I had a reproduction a fix was pretty easy. But, while I didn't have a reproduction, it was useful to add release assertions and watch crash dumps, to progressively zone in on this bug. 3. Adding new facilities to WebKit. You want stacks saved in memory on every platform? OK. https://bugs.webkit.org/show_bug.cgi?id=69018 WHAT DIDN'T WORK 1. Debuggers. Hackers who should have known better looked at release minidumps and symbols, and couldn't understand the variables. For a good example of this mistake from me, see http://code.google.com/p/chromium/issues/detail?id=75604#c21 . Want to see someone even smarter make the same mistake? http://code.google.com/p/chromium/issues/detail?id=75604#c43 The ScriptElement wasn't bogus, but the symbols data was. The symbols indicated ECX had this, when this was actually in EAX at the time, or [ESP]. Don't trust symbols in release builds; instead dissassemble the function, and figure out where the data is. The symbols probably said ECX because at the point of first dereference or maybe at call time, in that scope, this was probably in ECX. But in optimised code, that doesn't have much to do with anything anywhere else in the code. Read the dissassembly. 2. Reading code. I spent far, far too much time doing this. You know what, usually this works for me: I read code, consider the stack, have an AHA! moment, and fix my bug. Too bad this bug was beyond my cognitive horizon, and reading code was just a great way to waste time. 3. Not watching crashes. See comments 30 and 31 in the bug: http://code.google.com/p/chromium/issues/detail?id=75604#c30 . We should not have had confidence the problem was solved; since, hey, it wasn't. SPECIAL THANKS TO a...@webkit.org for encouraging me to instrument where it helps. cbent...@chromium.org for putting up with my yak shaving. ero...@chromium.org for showing me how to use windb(a)g. jap...@chromium.org for never giving up hope. On 2 November 2011 12:06, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote: I just finished fixing http://crbug.com/75604 aka
[webkit-dev] EventConstructors.h
This file seems to be growing a list of ever feature in the project: Source/WebCore/bindings/generic/EventConstructors.h Can we generate this file from the event IDL files? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EventConstructors.h
Sounds good. I created a bug (https://bugs.webkit.org/show_bug.cgi?id=71379). Let me try. 2011年11月2日11:02 Adam Barth aba...@webkit.org: This file seems to be growing a list of ever feature in the project: Source/WebCore/bindings/generic/EventConstructors.h Can we generate this file from the event IDL files? Adam -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EventConstructors.h
It should long term be generated from the EventInit dictionary IDLs, but it was handy to implement it in a macro based DSL initially. -Sam On Nov 2, 2011, at 11:02 AM, Adam Barth wrote: This file seems to be growing a list of ever feature in the project: Source/WebCore/bindings/generic/EventConstructors.h Can we generate this file from the event IDL files? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Moving WTF out of JavaScriptCore (revisited)
As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:23 PM, Adam Barth aba...@webkit.org wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) That'd be most excellent. ChangeLog would be cleanly split out as a nice side effect to doing this, as well as w/ WTF vs. JavaScriptCore. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Nov 2, 2011, at 4:42 PM, Darin Adler wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. Or maybe these will be statically linked libraries? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On 2011-11-02, at 16:42, Darin Adler wrote: On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. My current line of thinking was that WTF would build as a static library. JavaScriptCore's existing mechanism for exporting symbols should be sufficient to ensure that the necessary WTF symbols are still exposed. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 16:32, Adam Barth wrote: On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote: On 2011-11-02, at 13:23, Adam Barth wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. Yes. These are the goals. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. I don't see any benefit or need to move existing Xcode projects as part of this process. Can you expand on why you included this in your proposal? Based on our previous discussions, I was unsure how difficult (3) was on your end. If we can make (a) and (b) happen in the near term without moving xcodeproj files around, that would make me a happy camper. The code moving and the new Xcode project is relatively easy. I'm not sure what will be involved in updating all of the other build systems though. I'm happy to coordinate that part of the effort. I'm not entirely clear on what we'll need to do to tackle c). My current feeling is that it will mainly involve reshuffling of Apple's build processes rather than any significant changes to WebKit. Maybe we should aim to do (a) first, then (b), and then work on (c) once we've figured out what needs to happen on Apple's end? My recollection of the situation with WebCore/platform is that there are a number of existing layering violations in some ports. Given the approach outlined above I suspect they may need to be addressed before we can start making progress on b). Yes. Fixing these issues is going to be a fair amount of work. Perhaps it would make sense to create a stub Platform project for now, which will let us move code from WebCore/platform into Platform as we clean up the dependencies. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
