102827 2012-11-20 11:47:20 -0800 [EFL] Optimize binary size by removing dead sections on unix/gcc 2012-12-06 10:19:32 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 laszlo.gombos webkit-unassigned dglazkov d-r gyuyoung.kim loki mxie paroga rakuco rwlbuis ryuan.choi tmpsantos webkit.review.bot oldest_to_newest 772054 0 laszlo.gombos 2012-11-20 11:47:20 -0800 Turn on -ffunction-sections and -fdata-sections gcc flags and --gc-sections linker flag. 772065 1 175257 laszlo.gombos 2012-11-20 12:02:19 -0800 Created attachment 175257 turn on -ffunction-sections -fdata-sections --gc-section In my environment (EFL port, WebKit2, 64 bit Linux, gold linker) the saving on the stripped binary is about 1.88Mb (5.64% of the original binary size) 772077 2 175257 paroga 2012-11-20 12:13:37 -0800 Comment on attachment 175257 turn on -ffunction-sections -fdata-sections --gc-section View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review Only a style comment, since I don't use it on Linux. > Source/cmake/OptionsCommon.cmake:39 > + SET(CMAKE_C_FLAGS "-ffunction-sections -fdata-sections ${CMAKE_C_FLAGS}") > + SET(CMAKE_CXX_FLAGS "-ffunction-sections -fdata-sections ${CMAKE_CXX_FLAGS}") Usually this is written as SET(VAR "${VAR} additonalStuff") 772103 3 175257 rakuco 2012-11-20 13:05:34 -0800 Comment on attachment 175257 turn on -ffunction-sections -fdata-sections --gc-section View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review With regard to the compiler flags, gcc's man page says: Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker will create larger object and executable files and will also be slower. You will not be able to use "gprof" on all systems if you specify this option and you may have problems with debugging if you specify both this option and -g. This sounds quite alarming; what if you just change the linker flags? Is there much difference if you compare gold and ld? With my packager hat on, when a program uses unusual compiler or linker flags by default it tends to trigger my spider-sense; is there any trade-off we're not aware of when enabling these flags? > Source/cmake/OptionsCommon.cmake:37 > +IF (CMAKE_COMPILER_IS_GNUCC AND UNIX AND NOT APPLE) This is similar to the check we have in the WEBKIT_SET_EXTRA_COMPILER_FLAGS macro, so I wonder why this was not just put there. 772198 4 laszlo.gombos 2012-11-20 15:00:15 -0800 (In reply to comment #3) > (From update of attachment 175257 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review > > Source/cmake/OptionsCommon.cmake:37 > > +IF (CMAKE_COMPILER_IS_GNUCC AND UNIX AND NOT APPLE) > > This is similar to the check we have in the WEBKIT_SET_EXTRA_COMPILER_FLAGS macro, so I wonder why this was not just put there. I am not quite sure what is the best way to determine which rule goes to WebKitHelpers.cmake and OptionsCommon.cmake. OptionsCommon.cmake has similar rules as well (see for example the rule to set no-keep-memory linker flag in certain conditions. Should I move the "no-keep-memory linker flag" to WebKitHelpers.cmake as well ? It would be great to add a few lines description to each file to help to understand what goes where. I will reflect on your other comments once I have some data. Thanks for the help. 774681 5 laszlo.gombos 2012-11-23 12:24:10 -0800 (In reply to comment #2) > (From update of attachment 175257 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review > > + SET(CMAKE_CXX_FLAGS "-ffunction-sections -fdata-sections ${CMAKE_CXX_FLAGS}") > > Usually this is written as SET(VAR "${VAR} additonalStuff") Patrick, I think the order actually matters and variables that can be tweaked by the user as well should be prepended by the build system and not appended, see also bug 103101. You have a point that the patch was not consistent as the compiler flags were prepended but the linker flags were appended - I will change the linker flags so that they are prepended as well. 774899 6 laszlo.gombos 2012-11-24 16:35:38 -0800 (In reply to comment #3) > (From update of attachment 175257 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=175257&action=review > With regard to the compiler flags, gcc's man page says: > > Only use these options when there are significant benefits from > doing so. From my experience this optimization usually carries significant benefit for large projects where there is potential for dead symbols and where binary size matters. In case of WebKit EFL port I think that ~ 2Mb binary size saving is a significant benefit. From other WebKit ports the chromium port (see http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi) and Qt port (see http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.pri) have the same optimization turned on. Mozilla has it enabled as well - http://hg.mozilla.org/mozilla-central/file/f42a83257653/build/autoconf/compiler-opts.m4. > When you specify these options, the assembler and linker > will create larger object and executable files and will also be > slower. I ran some performance benchmarks (sunspider, v8, dromaeo DOM core tests) and have not been able to observe a difference in execution speed and memory usage (these tests fluctuate quite a bit and the results were always in the same range). If you can think of a particular case where you expect a regression, please let us know and we should try to test it as I certainly could not test it all. I was also expecting an increased build/linking time, but at least for incremental linking I could not find an evidence of that (only tried with gold). > You will not be able to use "gprof" on all systems if you specify this option This is a valid point and we should be able to work around it in the build system (like the other projects did). See also the related discussion about the precendence of user specified build options. > and [...] you may have problems with debugging if you > specify both this option and -g. I see no compelling reason to turn this on for debug builds. I will change the patch to only enable the flag for release builds. > This sounds quite alarming; what if you just change the linker flags? These flags should really go hand in hand - this is probably one reason why it is not the default in gcc. The saving in size for the linker-flags-only build is only about 236kB. > Is there much difference if you compare gold and ld? Not much. Gold saves 28kB more. > With my packager hat on, when a program uses unusual compiler or linker flags by default it tends to trigger my spider-sense; is there any trade-off we're not aware of when enabling these flags? I agree that as most compiler flags this is probably also a trade-off. In WebKit most of the really hot code is already optimized (e.g. JIT). In addition to these new flags in the patch the build system for EFL uses -O3 (which the CMake default) which makes performance a preference over binary size so in this combination of flags I could not demonstrate any performance difference for WebKit. I would recommend to use these flags in any production environment - and becase of that I think we should also have it set in the buildbot so that it is tested. If some distribution/packager decides that this is not what they want they can just overrule it using environment variables. To disable these options one can use the following build command (I tested it): build-webkit --efl --cmakearg="-DCMAKE_C_FLAGS='-fno-function-sections -fno-data-sections' -DCMAKE_CXX_FLAGS='-fno-function-sections -fno-data-sections' -DCMAKE_SHARED_LINKER_FLAGS='-Wl,--no-gc-sections'" 774900 7 laszlo.gombos 2012-11-24 16:39:05 -0800 Ming or Rob what do you think we should do for the BlackBerry port (which is the only other port using CMake and GCC) ? Should this be introduced initially only for the EFL port or we should turn this on for the BlackBerry port as well ? Do you have some numbers that you can share in therm of benefits in the BlackBerry environment ? 774905 8 175870 laszlo.gombos 2012-11-24 17:48:53 -0800 Created attachment 175870 turn on optimization only for release builds and make sure that it can be disabled by a packager 774981 9 175870 webkit.review.bot 2012-11-25 08:36:07 -0800 Comment on attachment 175870 turn on optimization only for release builds and make sure that it can be disabled by a packager Attachment 175870 did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14984338 New failing tests: svg/W3C-SVG-1.1/animate-elem-78-t.svg 775004 10 mxie 2012-11-25 10:26:46 -0800 I tried this out with our BlackBerry port, and I see the binary size went up. :-( I talked to our tools guy, and he said, "These functions can lead to bloat if there's no sections to garbage collect." Let's leave this out from the BlackBerry port if you guys want to land this now. 777284 11 ryuan.choi 2012-11-27 15:51:11 -0800 (In reply to comment #10) > I tried this out with our BlackBerry port, and I see the binary size went up. :-( > > I talked to our tools guy, and he said, "These functions can lead to bloat if there's no sections to garbage collect." > > Let's leave this out from the BlackBerry port if you guys want to land this now. In tizen, it reduced binary size about 3Mb 777448 12 175870 laszlo.gombos 2012-11-27 18:38:39 -0800 Comment on attachment 175870 turn on optimization only for release builds and make sure that it can be disabled by a packager Removing r? as this patch needs to be reworked. I plan to create a patch that turns this optimization on just for the EFL port after I run a few more tests. 783224 13 laszlo.gombos 2012-12-04 18:29:51 -0800 (In reply to comment #10) > I tried this out with our BlackBerry port, and I see the binary size went up. :-( > > I talked to our tools guy, and he said, "These functions can lead to bloat if there's no sections to garbage collect." > > Let's leave this out from the BlackBerry port if you guys want to land this now. Thanks Ming, I appreciate for checking this. It seems that there is plenty of garbage to collect for the EFL port at the moment (and this might change over time). It is certainly interesting to see such a big difference in different ports and different tool chain. 783225 14 177640 laszlo.gombos 2012-12-04 18:31:05 -0800 Created attachment 177640 patch for the EFL port only 783248 15 177640 gyuyoung.kim 2012-12-04 19:05:20 -0800 Comment on attachment 177640 patch for the EFL port only I agree to land this for EFL and Tizen platform. CMake guys might want to have a final look. 783254 16 177640 gyuyoung.kim 2012-12-04 19:09:38 -0800 Comment on attachment 177640 patch for the EFL port only I'd like to set r+ again after getting cmake guys informal review. 784983 17 178021 laszlo.gombos 2012-12-06 09:40:41 -0800 Created attachment 178021 for cq to land Rebased. 785012 18 178021 webkit.review.bot 2012-12-06 10:19:26 -0800 Comment on attachment 178021 for cq to land Clearing flags on attachment: 178021 Committed r136854: <http://trac.webkit.org/changeset/136854> 785013 19 webkit.review.bot 2012-12-06 10:19:32 -0800 All reviewed patches have been landed. Closing bug. 175257 2012-11-20 12:02:19 -0800 2012-11-24 17:48:53 -0800 turn on -ffunction-sections -fdata-sections --gc-section 102827.patch text/plain 1653 laszlo.gombos SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDEzNTMw MykKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTEx LTIwICBMYXN6bG8gR29tYm9zICA8bC5nb21ib3NAc2Ftc3VuZy5jb20+CisKKyAgICAgICAgW0NN YWtlXSBPcHRpbWl6ZSBiaW5hcnkgc2l6ZSBieSByZW1vdmluZyBkZWFkIHNlY3Rpb25zIG9uIHVu aXgvZ2NjCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0x MDI4MjcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBU dXJuIG9uIC1mZnVuY3Rpb24tc2VjdGlvbnMgYW5kIC1mZGF0YS1zZWN0aW9ucyBnY2MgZmxhZ3Mg YW5kCisgICAgICAgIHRoZSAtLWdjLXNlY3Rpb25zIGxpbmtlciBmbGFnIG9uIFVuaXggc3lzdGVt cyBmb3IgYWxsIENNYWtlIGJhc2VkCisgICAgICAgIGJ1aWxkcy4KKworICAgICAgICAqIFNvdXJj ZS9jbWFrZS9PcHRpb25zQ29tbW9uLmNtYWtlOgorCiAyMDEyLTExLTIwICBDYXJsb3MgR2FyY2lh IENhbXBvcyAgPGNnYXJjaWFAaWdhbGlhLmNvbT4KIAogICAgICAgICBVbnJldmlld2VkLiBVcGRh dGUgTkVXUyBhbmQgY29uZmlndXJlLmFjIGZvciAxLjExLjIgcmVsZWFzZQpJbmRleDogU291cmNl L2NtYWtlL09wdGlvbnNDb21tb24uY21ha2UKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL2NtYWtlL09w dGlvbnNDb21tb24uY21ha2UJKHJldmlzaW9uIDEzNTIzMSkKKysrIFNvdXJjZS9jbWFrZS9PcHRp b25zQ29tbW9uLmNtYWtlCSh3b3JraW5nIGNvcHkpCkBAIC0zMyw2ICszMywxMyBAQCBJRiAoIiR7 Q01BS0VfQ1hYX0NPTVBJTEVSX0lEfSIgU1RSRVFVQUwKICAgICBTRVQoQ01BS0VfU0hBUkVEX0xJ TktFUl9GTEFHUyAiJHtDTUFLRV9TSEFSRURfTElOS0VSX0ZMQUdTfSAtV2wsLS1uby1rZWVwLW1l bW9yeSIpCiBFTkRJRiAoKQogCisjIE9wdGltaXplIGJpbmFyeSBzaXplIGJ5IHJlbW92aW5nIGRl YWQgc2VjdGlvbnMgb24gdW5peC9nY2MKK0lGIChDTUFLRV9DT01QSUxFUl9JU19HTlVDQyBBTkQg VU5JWCBBTkQgTk9UIEFQUExFKQorICAgIFNFVChDTUFLRV9DX0ZMQUdTICItZmZ1bmN0aW9uLXNl Y3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAke0NNQUtFX0NfRkxBR1N9IikKKyAgICBTRVQoQ01BS0Vf Q1hYX0ZMQUdTICItZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAke0NNQUtFX0NY WF9GTEFHU30iKQorICAgIFNFVChDTUFLRV9TSEFSRURfTElOS0VSX0ZMQUdTICIke0NNQUtFX1NI QVJFRF9MSU5LRVJfRkxBR1N9IC1XbCwtLWdjLXNlY3Rpb25zIikKK0VORElGICgpCisKIFNFVChM SUJfU1VGRklYICIiIENBQ0hFIFNUUklORyAiRGVmaW5lIHN1ZmZpeCBvZiBkaXJlY3RvcnkgbmFt ZSAoMzIvNjQpIikKIAogU0VUKExJQl9JTlNUQUxMX0RJUiAibGliJHtMSUJfU1VGRklYfSIgQ0FD SEUgUEFUSCAiV2hlcmUgdG8gaW5zdGFsbCBsaWJyYXJpZXMgKGxpYiR7TElCX1NVRkZJWH0pIikK 175870 2012-11-24 17:48:53 -0800 2012-12-06 10:50:06 -0800 turn on optimization only for release builds and make sure that it can be disabled by a packager 102827.patch text/plain 1722 laszlo.gombos SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDEzNTY1 OSkKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTEx LTI0ICBMYXN6bG8gR29tYm9zICA8bC5nb21ib3NAc2Ftc3VuZy5jb20+CisKKyAgICAgICAgW0NN YWtlXSBPcHRpbWl6ZSBiaW5hcnkgc2l6ZSBieSByZW1vdmluZyBkZWFkIHNlY3Rpb25zIG9uIHVu aXgvZ2NjCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0x MDI4MjcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBU dXJuIG9uIC1mZnVuY3Rpb24tc2VjdGlvbnMgLWZkYXRhLXNlY3Rpb25zIC0tZ2Mtc2VjdGlvbiBm bGFncworICAgICAgICBvbiB1bml4IGZvciB0aGUgZ2NjIHRvb2xjaGFpbiBmb3IgcmVsZWFzZSBi dWlsZHMgdG8gb3B0aW1pemUgYmluYXJ5CisgICAgICAgIHNpemUuCisKKyAgICAgICAgKiBTb3Vy Y2UvY21ha2UvT3B0aW9uc0NvbW1vbi5jbWFrZToKKwogMjAxMi0xMS0yMyAgQWxleGlzIE1lbmFy ZCAgPGFsZXhpc0B3ZWJraXQub3JnPgogCiAgICAgICAgIFtDU1MzIEJhY2tncm91bmRzIGFuZCBC b3JkZXJzXSBJbXBsZW1lbnQgbmV3IENTUzMgYmFja2dyb3VuZC1wb3NpdGlvbiBwYXJzaW5nLgpJ bmRleDogU291cmNlL2NtYWtlL09wdGlvbnNDb21tb24uY21ha2UKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL2NtYWtlL09wdGlvbnNDb21tb24uY21ha2UJKHJldmlzaW9uIDEzNTIzMSkKKysrIFNvdXJj ZS9jbWFrZS9PcHRpb25zQ29tbW9uLmNtYWtlCSh3b3JraW5nIGNvcHkpCkBAIC0zMyw2ICszMywx MyBAQCBJRiAoIiR7Q01BS0VfQ1hYX0NPTVBJTEVSX0lEfSIgU1RSRVFVQUwKICAgICBTRVQoQ01B S0VfU0hBUkVEX0xJTktFUl9GTEFHUyAiJHtDTUFLRV9TSEFSRURfTElOS0VSX0ZMQUdTfSAtV2ws LS1uby1rZWVwLW1lbW9yeSIpCiBFTkRJRiAoKQogCisjIE9wdGltaXplIGJpbmFyeSBzaXplIGZv ciByZWxlYXNlIGJ1aWxkcyBieSByZW1vdmluZyBkZWFkIHNlY3Rpb25zIG9uIHVuaXgvZ2NjCitJ RiAoQ01BS0VfQlVJTERfVFlQRSBTVFJFUVVBTCBSZWxlYXNlIEFORCBDTUFLRV9DT01QSUxFUl9J U19HTlVDQyBBTkQgVU5JWCBBTkQgTk9UIEFQUExFKQorICAgIFNFVChDTUFLRV9DX0ZMQUdTICIt ZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAke0NNQUtFX0NfRkxBR1N9IikKKyAg ICBTRVQoQ01BS0VfQ1hYX0ZMQUdTICItZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9u cyAke0NNQUtFX0NYWF9GTEFHU30iKQorICAgIFNFVChDTUFLRV9TSEFSRURfTElOS0VSX0ZMQUdT ICItV2wsLS1nYy1zZWN0aW9ucyAke0NNQUtFX1NIQVJFRF9MSU5LRVJfRkxBR1N9IikKK0VORElG ICgpCisKIFNFVChMSUJfU1VGRklYICIiIENBQ0hFIFNUUklORyAiRGVmaW5lIHN1ZmZpeCBvZiBk aXJlY3RvcnkgbmFtZSAoMzIvNjQpIikKIAogU0VUKExJQl9JTlNUQUxMX0RJUiAibGliJHtMSUJf U1VGRklYfSIgQ0FDSEUgUEFUSCAiV2hlcmUgdG8gaW5zdGFsbCBsaWJyYXJpZXMgKGxpYiR7TElC X1NVRkZJWH0pIikK 177640 2012-12-04 18:31:05 -0800 2012-12-06 09:40:41 -0800 patch for the EFL port only 102827.patch text/plain 1591 laszlo.gombos SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDEzNjU4 NCkKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTEy LTA0ICBMYXN6bG8gR29tYm9zICA8bC5nb21ib3NAc2Ftc3VuZy5jb20+CisKKyAgICAgICAgW0VG TF0gT3B0aW1pemUgYmluYXJ5IHNpemUgYnkgcmVtb3ZpbmcgZGVhZCBzZWN0aW9ucyBvbiB1bml4 L2djYworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTAy ODI3CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVHVy biBvbiAtZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtLWdjLXNlY3Rpb24gZmxh Z3MKKyAgICAgICAgb24gdW5peCBmb3IgdGhlIGdjYyB0b29sY2hhaW4gZm9yIHJlbGVhc2UgYnVp bGRzIHRvIG9wdGltaXplIGJpbmFyeQorICAgICAgICBzaXplIGZvciB0aGUgRWZsIHBvcnQuCisK KyAgICAgICAgKiBTb3VyY2UvY21ha2UvT3B0aW9uc0VmbC5jbWFrZToKKwogMjAxMi0xMi0wNCAg S29uZGFwYWxseSBLYWx5YW4gIDxrYWx5YW4ua29uZGFwYWxseUBpbnRlbC5jb20+CiAKICAgICAg ICAgW0VGTF1bV0syXVtBQ10gVVNFX0dSQVBISUNTX1NVUkZBQ0Ugc2hvdWxkIGJlIGVuYWJsZWQg b25seSBpZiBYY29tcG9zaXRlIGFuZCBYcmVuZGVyIGV4dGVuc2lvbnMgYXJlIGZvdW5kLgpJbmRl eDogU291cmNlL2NtYWtlL09wdGlvbnNFZmwuY21ha2UKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL2Nt YWtlL09wdGlvbnNFZmwuY21ha2UJKHJldmlzaW9uIDEzNjU4NCkKKysrIFNvdXJjZS9jbWFrZS9P cHRpb25zRWZsLmNtYWtlCSh3b3JraW5nIGNvcHkpCkBAIC0xNzcsNiArMTc3LDEzIEBAIEVORElG ICgpCiAKIFNFVChDUEFDS19TT1VSQ0VfR0VORVJBVE9SIFRCWjIpCiAKKyMgT3B0aW1pemUgYmlu YXJ5IHNpemUgZm9yIHJlbGVhc2UgYnVpbGRzIGJ5IHJlbW92aW5nIGRlYWQgc2VjdGlvbnMgb24g dW5peC9nY2MKK0lGIChDTUFLRV9CVUlMRF9UWVBFIFNUUkVRVUFMIFJlbGVhc2UgQU5EIENNQUtF X0NPTVBJTEVSX0lTX0dOVUNDIEFORCBVTklYIEFORCBOT1QgQVBQTEUpCisgICAgU0VUKENNQUtF X0NfRkxBR1MgIi1mZnVuY3Rpb24tc2VjdGlvbnMgLWZkYXRhLXNlY3Rpb25zICR7Q01BS0VfQ19G TEFHU30iKQorICAgIFNFVChDTUFLRV9DWFhfRkxBR1MgIi1mZnVuY3Rpb24tc2VjdGlvbnMgLWZk YXRhLXNlY3Rpb25zICR7Q01BS0VfQ1hYX0ZMQUdTfSIpCisgICAgU0VUKENNQUtFX1NIQVJFRF9M SU5LRVJfRkxBR1MgIi1XbCwtLWdjLXNlY3Rpb25zICR7Q01BS0VfU0hBUkVEX0xJTktFUl9GTEFH U30iKQorRU5ESUYgKCkKKwogSUYgKFdURl9VU0VfVElMRURfQkFDS0lOR19TVE9SRSkKICAgQURE X0RFRklOSVRJT05TKC1EV1RGX1VTRV9BQ0NFTEVSQVRFRF9DT01QT1NJVElORz0xKQogCg== 178021 2012-12-06 09:40:41 -0800 2012-12-06 10:19:26 -0800 for cq to land 102827.patch text/plain 1541 laszlo.gombos SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDEzNjg0 MykKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDEyLTEy LTA2ICBMYXN6bG8gR29tYm9zICA8bC5nb21ib3NAc2Ftc3VuZy5jb20+CisKKyAgICAgICAgW0VG TF0gT3B0aW1pemUgYmluYXJ5IHNpemUgYnkgcmVtb3ZpbmcgZGVhZCBzZWN0aW9ucyBvbiB1bml4 L2djYworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTAy ODI3CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgS2VubmV0aCBSb2hkZSBDaHJpc3RpYW5zZW4uCisK KyAgICAgICAgVHVybiBvbiAtZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtLWdj LXNlY3Rpb24gZmxhZ3MKKyAgICAgICAgb24gdW5peCBmb3IgdGhlIGdjYyB0b29sY2hhaW4gZm9y IHJlbGVhc2UgYnVpbGRzIHRvIG9wdGltaXplIGJpbmFyeQorICAgICAgICBzaXplIGZvciB0aGUg RWZsIHBvcnQuCisKKyAgICAgICAgKiBTb3VyY2UvY21ha2UvT3B0aW9uc0VmbC5jbWFrZToKKwog MjAxMi0xMi0wNiAgU2Vva2p1IEt3b24gIDxzZW9ranUua3dvbkBnbWFpbC5jb20+CiAKICAgICAg ICAgW0VGTF0gRml4IGRlc3RpbmF0aW9uIHBhdGggaW4gU291cmNlL1BsYXRmb3JtRWZsLmNtYWtl CkluZGV4OiBTb3VyY2UvY21ha2UvT3B0aW9uc0VmbC5jbWFrZQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy Y2UvY21ha2UvT3B0aW9uc0VmbC5jbWFrZQkocmV2aXNpb24gMTM2ODQzKQorKysgU291cmNlL2Nt YWtlL09wdGlvbnNFZmwuY21ha2UJKHdvcmtpbmcgY29weSkKQEAgLTE3Nyw2ICsxNzcsMTMgQEAg ZW5kaWYgKCkKIAogc2V0KENQQUNLX1NPVVJDRV9HRU5FUkFUT1IgVEJaMikKIAorIyBPcHRpbWl6 ZSBiaW5hcnkgc2l6ZSBmb3IgcmVsZWFzZSBidWlsZHMgYnkgcmVtb3ZpbmcgZGVhZCBzZWN0aW9u cyBvbiB1bml4L2djYworaWYgKENNQUtFX0JVSUxEX1RZUEUgU1RSRVFVQUwgUmVsZWFzZSBBTkQg Q01BS0VfQ09NUElMRVJfSVNfR05VQ0MgQU5EIFVOSVggQU5EIE5PVCBBUFBMRSkKKyAgICBzZXQo Q01BS0VfQ19GTEFHUyAiLWZmdW5jdGlvbi1zZWN0aW9ucyAtZmRhdGEtc2VjdGlvbnMgJHtDTUFL RV9DX0ZMQUdTfSIpCisgICAgc2V0KENNQUtFX0NYWF9GTEFHUyAiLWZmdW5jdGlvbi1zZWN0aW9u cyAtZmRhdGEtc2VjdGlvbnMgJHtDTUFLRV9DWFhfRkxBR1N9IikKKyAgICBzZXQoQ01BS0VfU0hB UkVEX0xJTktFUl9GTEFHUyAiLVdsLC0tZ2Mtc2VjdGlvbnMgJHtDTUFLRV9TSEFSRURfTElOS0VS X0ZMQUdTfSIpCitlbmRpZiAoKQorCiBpZiAoV1RGX1VTRV9USUxFRF9CQUNLSU5HX1NUT1JFKQog ICAgIGFkZF9kZWZpbml0aW9ucygtRFdURl9VU0VfQUNDRUxFUkFURURfQ09NUE9TSVRJTkc9MSkK IAo=