164588 2016-11-10 05:45:38 -0800 [JSC] Build broken for 32-bit x86 after r208306 with GCC 4.9 2016-11-16 13:01:16 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=163562 P2 Normal --- 1 clopez clopez benjamin bugs-noreply cdumez cgarcia cmarcelo commit-queue dbates fpizlo ggaren gustavo keith_miller mark.lam mcatanzaro ossy ysuzuki oldest_to_newest 1249763 0 clopez 2016-11-10 05:45:38 -0800 Building WebKitGTK+ (and I guess any other Linux port) after r208306 <http://trac.webkit.org/r208306> causes this: g++-4.9 [.....] -o Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/heap/Heap.cpp.o -c ../../Source/JavaScriptCore/heap/Heap.cpp In file included from ../../Source/WTF/wtf/Lock.h:29:0, from ../../Source/WTF/wtf/HashTable.h:33, from ../../Source/WTF/wtf/HashMap.h:25, from ../../Source/JavaScriptCore/runtime/JSCJSValue.h:33, from ../../Source/JavaScriptCore/heap/HandleTypes.h:28, from ../../Source/JavaScriptCore/heap/Handle.h:28, from ../../Source/JavaScriptCore/heap/HandleSet.h:28, from ../../Source/JavaScriptCore/heap/Heap.h:27, from ../../Source/JavaScriptCore/heap/Heap.cpp:22: ../../Source/WTF/wtf/Atomics.h: In member function 'bool JSC::Heap::handleGCDidJIT(unsigned int)': ../../Source/WTF/wtf/Atomics.h:245:20: error: inconsistent operand constraints in an 'asm' : "memory"); ^ https://build.webkit.org/builders/GTK%20Linux%2032-bit%20Release/builds/65378/steps/compile-webkit/logs/stdio/text This is the function causing the issue: inline void x86_cpuid() { #if OS(WINDOWS) int info[4]; __cpuid(info, 0); #else intptr_t a = 0, b, c, d; asm volatile( "cpuid" : "+a"(a), "=b"(b), "=c"(c), "=d"(d) : : "memory"); #endif } Seems GCC 4.9 doesn't like it on 32-bit The build failure is not reproducible with newer GCC (tested with GCC 5.3.1 and built fine) 1249766 1 clopez 2016-11-10 06:02:42 -0800 And this seems to be the right answer: http://stackoverflow.com/a/28976166 Removing -fPIC for that file from the compiler arguments makes it build 1249779 2 mcatanzaro 2016-11-10 06:55:31 -0800 Does it work, though??? Is it really possible to have a shared library with position-dependent code? I do not think removing -fPIC could be right...? 1249799 3 clopez 2016-11-10 08:35:42 -0800 (In reply to comment #2) > Does it work, though??? Is it really possible to have a shared library with > position-dependent code? I do not think removing -fPIC could be right...? What I tried was just removing the fPIC flag from JavaScriptCore/heap/Heap.cpp which is (right now) the only user of x86_cpuid() via crossModifyingCodeFence(). Doing this with cmake seems difficult (not even sure if its possible), because the fPIC argument gets passed automatically for any library via ${CMAKE_SHARED_LIBRARY_CXX_FLAGS} (for the whole library and not for a single file). So I managed to get it build by manually editing the ninja recipes generated to remove the fPIC variable from JavaScriptCore/heap/Heap.cpp It seems to work, but its hard to tell if something is broke as I don't even know what is the purpose of this crossModifyingCodeFence() thing or when its used. And removing -fPIC for the whole JavaScriptCore library seems not something we want to do in any case. I see crossModifyingCodeFence is defined as std::atomic_thread_fence(std::memory_order_seq_cst) for non x86 cpus. Maybe that could work also for an x86 cpu?. Another option is to modify that assembly to make it happy with gcc-4.9 on x86-32 bits. Here seems to be some interesting notes about this: http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well But is hard to try to modify that without knowing what is x86_cpuid() actually doing, how to test it, or what is the purpose of crossModifyingCodeFence(). Filip could you advice us what to do here to fix this? 1249853 4 clopez 2016-11-10 10:42:16 -0800 Ok.. i think now I understand better this. The purpose of executing the x86 assembly instruction cpuid on crossModifyingCodeFence() is just to force any modifications to registers, memory and flags to be completed and to drain all buffered writes to memory before the next instruction is fetched and executed. The value returned by cpuid is not used at all here. The idea is just to force this sync() on the cpu registers and memory.. right? Reference: https://jpassing.com/2015/01/19/runtime-code-modification-explained-part-2-cache-coherency-issues/ 1249882 5 294391 clopez 2016-11-10 11:38:58 -0800 Created attachment 294391 Patch 1249907 6 294391 mcatanzaro 2016-11-10 12:21:01 -0800 Comment on attachment 294391 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=294391&action=review > Source/WTF/wtf/Atomics.h:239 > +#elif CPU(X86) && defined(__PIC__) && __GNUC__ < 5 It will be a compiler warning on other compilers. Best check if it's defined before using it: && defined(__GNUC__) && __GNUC__ < 5 Do we want to run this code when using Clang? If not, then use this instead to filter out Clang: && COMPILER(GCC) && __GNUC__ < 5 1249936 7 294401 clopez 2016-11-10 13:12:55 -0800 Created attachment 294401 Patch Address Michael comments 1251431 8 clopez 2016-11-15 07:33:45 -0800 Ping reviewers? The GTK 32-bit buildbot has been red for several days already due to this <https://build.webkit.org/builders/GTK%20Linux%2032-bit%20Release> 1251442 9 294401 mcatanzaro 2016-11-15 08:35:01 -0800 Comment on attachment 294401 Patch I'd rather another reviewer look at it because I do not understand the code, but here's your rubber stamp. 1251443 10 mcatanzaro 2016-11-15 08:36:00 -0800 I'm suspicious that the code is only needed when using GCC. 1251457 11 294401 fpizlo 2016-11-15 09:31:36 -0800 Comment on attachment 294401 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=294401&action=review > Source/WTF/wtf/Atomics.h:248 > +#elif CPU(X86) && defined(__PIC__) && COMPILER(GCC) && __GNUC__ < 5 > + intptr_t a = 0, b, c, d; > + asm volatile( > + "pushl %%ebx;" // save %ebx > + "cpuid;" > + "movl %%ebx, %0;" // save what cpuid put in %ebx into the first output (b) > + "popl %%ebx;" // restore the old %ebx value > + : "=r"(b), "+a"(a), "=c"(c), "=d"(d) > + : > + : "memory"); You should just make this conditional on CPU(X86). Because cpuid is so expensive, we don't use this on code paths where the extra push/pop would be expensive. It's better to simplify the conditional just for sanity. You don't need to movl %%ebx, %0. We never use the results of a, b, c, d. The only point of those variables is as a way to tell the compiler that cpuid clobbers ax, bx, cx, and dx. But it seems that this version of GCC doesn't grok our clobbering of bx. So, I suggest something like this for x86-32: intptr_t a = 0, c, d; asm volatile( "pushl %%ebx\n\t" "cpuid\n\t" "popl %%ebx\n\t" : "+a"(a), "=c"(c), "=d"(d) : : "memory"); So, we still tell the compiler that this reads and writes ax, writes cx, and writes dx, but we don't tell the compiler about bx, because we know that the compiler might not understand this and because we preserve its value using push/pop. r- because I think that the movl is unnecessary. 1251548 12 clopez 2016-11-15 12:10:14 -0800 (In reply to comment #11) > Comment on attachment 294401 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=294401&action=review > > > Source/WTF/wtf/Atomics.h:248 > > +#elif CPU(X86) && defined(__PIC__) && COMPILER(GCC) && __GNUC__ < 5 > > + intptr_t a = 0, b, c, d; > > + asm volatile( > > + "pushl %%ebx;" // save %ebx > > + "cpuid;" > > + "movl %%ebx, %0;" // save what cpuid put in %ebx into the first output (b) > > + "popl %%ebx;" // restore the old %ebx value > > + : "=r"(b), "+a"(a), "=c"(c), "=d"(d) > > + : > > + : "memory"); > > You should just make this conditional on CPU(X86). Because cpuid is so > expensive, we don't use this on code paths where the extra push/pop would be > expensive. It's better to simplify the conditional just for sanity. > > You don't need to movl %%ebx, %0. We never use the results of a, b, c, d. > The only point of those variables is as a way to tell the compiler that > cpuid clobbers ax, bx, cx, and dx. But it seems that this version of GCC > doesn't grok our clobbering of bx. > > So, I suggest something like this for x86-32: > > intptr_t a = 0, c, d; > asm volatile( > "pushl %%ebx\n\t" > "cpuid\n\t" > "popl %%ebx\n\t" > : "+a"(a), "=c"(c), "=d"(d) > : > : "memory"); > > So, we still tell the compiler that this reads and writes ax, writes cx, and > writes dx, but we don't tell the compiler about bx, because we know that the > compiler might not understand this and because we preserve its value using > push/pop. > > r- because I think that the movl is unnecessary. The movl is necessary if you actually want to read what cpuid has returned, but since we don't care about that, we can just ignore it and avoid the movl. However, if you are concerned about the extra movl and about having more if-defs than necessary, why just don't use this both unconditionally for x86 and x64? I have checked what the compiler does, and doing it how you suggests avoids 2 movl call on x64 http://sprunge.us/SVKR (and 1 in x86) 1251553 13 fpizlo 2016-11-15 12:13:56 -0800 (In reply to comment #12) > (In reply to comment #11) > > Comment on attachment 294401 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=294401&action=review > > > > > Source/WTF/wtf/Atomics.h:248 > > > +#elif CPU(X86) && defined(__PIC__) && COMPILER(GCC) && __GNUC__ < 5 > > > + intptr_t a = 0, b, c, d; > > > + asm volatile( > > > + "pushl %%ebx;" // save %ebx > > > + "cpuid;" > > > + "movl %%ebx, %0;" // save what cpuid put in %ebx into the first output (b) > > > + "popl %%ebx;" // restore the old %ebx value > > > + : "=r"(b), "+a"(a), "=c"(c), "=d"(d) > > > + : > > > + : "memory"); > > > > You should just make this conditional on CPU(X86). Because cpuid is so > > expensive, we don't use this on code paths where the extra push/pop would be > > expensive. It's better to simplify the conditional just for sanity. > > > > You don't need to movl %%ebx, %0. We never use the results of a, b, c, d. > > The only point of those variables is as a way to tell the compiler that > > cpuid clobbers ax, bx, cx, and dx. But it seems that this version of GCC > > doesn't grok our clobbering of bx. > > > > So, I suggest something like this for x86-32: > > > > intptr_t a = 0, c, d; > > asm volatile( > > "pushl %%ebx\n\t" > > "cpuid\n\t" > > "popl %%ebx\n\t" > > : "+a"(a), "=c"(c), "=d"(d) > > : > > : "memory"); > > > > So, we still tell the compiler that this reads and writes ax, writes cx, and > > writes dx, but we don't tell the compiler about bx, because we know that the > > compiler might not understand this and because we preserve its value using > > push/pop. > > > > r- because I think that the movl is unnecessary. > > The movl is necessary if you actually want to read what cpuid has returned, > but since we don't care about that, we can just ignore it and avoid the movl. > > However, if you are concerned about the extra movl and about having more > if-defs than necessary, why just don't use this both unconditionally for x86 > and x64? I'm happy with that, but it gets awkward when telling the compiler that you want to push ebx. On x86-32 you would say pushl ebx, while on x86-64 you would say pushq rbx. If you can find a clever way around this then I'm happy with this code being shared. That would be the best. > > I have checked what the compiler does, and doing it how you suggests avoids > 2 movl call on x64 http://sprunge.us/SVKR (and 1 in x86) 1251571 14 clopez 2016-11-15 12:51:31 -0800 (In reply to comment #13) > > > > The movl is necessary if you actually want to read what cpuid has returned, > > but since we don't care about that, we can just ignore it and avoid the movl. > > > > However, if you are concerned about the extra movl and about having more > > if-defs than necessary, why just don't use this both unconditionally for x86 > > and x64? > > I'm happy with that, but it gets awkward when telling the compiler that you > want to push ebx. On x86-32 you would say pushl ebx, while on x86-64 you > would say pushq rbx. If you can find a clever way around this then I'm > happy with this code being shared. That would be the best. > Mmmm, good point. I was overlooking that in 64-bit the instructions and the registers are different :| So, I guess that using this for x86 only is the best thing I can come with. 1251584 15 294870 clopez 2016-11-15 13:09:21 -0800 Created attachment 294870 Patch Avoid a movl call and make it conditional for CPU(X86) 1251946 16 clopez 2016-11-16 12:03:06 -0800 Filip please, could you review this patch? The GTK 32-bit buildbot continues to be broken due to this. I understand it should be quick to review. Thanks 1251973 17 294870 mark.lam 2016-11-16 12:50:01 -0800 Comment on attachment 294870 Patch r=me because Filip has already reviewed this previously and suggested this specific fix. 1251981 18 clopez 2016-11-16 12:59:46 -0800 (In reply to comment #17) > Comment on attachment 294870 [details] > Patch > > r=me because Filip has already reviewed this previously and suggested this > specific fix. Thanks! 1251983 19 294870 clopez 2016-11-16 13:01:05 -0800 Comment on attachment 294870 Patch Clearing flags on attachment: 294870 Committed r208806: <http://trac.webkit.org/changeset/208806> 1251984 20 clopez 2016-11-16 13:01:16 -0800 All reviewed patches have been landed. Closing bug. 294391 2016-11-10 11:38:58 -0800 2016-11-10 13:12:29 -0800 Patch bug-164588-20161110203445.patch text/plain 1831 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjA4NTM4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IGJmZjllOGVlYzA4MTUzZGRhMDM1ZDc4 NTVmMTNhZGE2MjQ4MGE1NDcuLjhmNTg5NzJhNDJlMGU3OWRmMjM3YzAxZDVjMWJiNTU1OWYwYzQ4 MjQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjEgQEAKKzIwMTYtMTEtMTAgIENhcmxvcyBBbGJlcnRvIExvcGV6 IFBlcmV6ICA8Y2xvcGV6QGlnYWxpYS5jb20+CisKKyAgICAgICAgW0pTQ10gQnVpbGQgYnJva2Vu IGZvciAzMi1iaXQgeDg2IGFmdGVyIHIyMDgzMDYgd2l0aCBHQ0MgNC45CisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjQ1ODgKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBQcm92aWRlIGFzc2VtYmx5IGZvciBl eGVjdXRpbmcgdGhlIGNwdWlkIGluc3RydWN0aW9uIHdoZW4gY29tcGlsaW5nCisgICAgICAgIGlu IFBJQyBtb2RlIHdpdGggdGhlIEdDQyA0LjkgRUJYIG9uIDMyLWJpdCB4ODYuCisKKyAgICAgICAg Tm90ZSB0aGF0IHRoZSB2YWx1ZXMgcmV0dXJuZWQgYnkgY3B1aWQgaGVyZSBhcmUgbm90IHVzZWQu IFRoZSBwdXJwb3NlCisgICAgICAgIG9mIGNhbGxpbmcgdGhpcyBpbnN0cnVjdGlvbiBpcyB0byBm b3JjZSB0aGUgQ1BVIHRvIGNvbXBsZXRlIGFuZCBzeW5jCisgICAgICAgIGFueSBidWZmZXJlZCBt b2RpZmljYXRpb25zIG9uIHJlZ2lzdGVycywgbWVtb3J5IG9yIGZsYWdzIGJlZm9yZQorICAgICAg ICBmZXRjaGluZyBhbmQgZXhlY3V0aW5nIHRoZSBuZXh0IGluc3RydWN0aW9uLgorCisgICAgICAg ICogd3RmL0F0b21pY3MuaDoKKyAgICAgICAgKFdURjo6eDg2X2NwdWlkKToKKwogMjAxNi0xMS0w OSAgQWxleCBDaHJpc3RlbnNlbiAgPGFjaHJpc3RlbnNlbkB3ZWJraXQub3JnPgogCiAgICAgICAg IEFsbG93IFJlZlB0cnMgb2YgY29uc3QgVGhyZWFkU2FmZVJlZkNvdW50ZWQgdHlwZXMKZGlmZiAt LWdpdCBhL1NvdXJjZS9XVEYvd3RmL0F0b21pY3MuaCBiL1NvdXJjZS9XVEYvd3RmL0F0b21pY3Mu aAppbmRleCA5YjlhMmY3ODg3YTVmMzE5OWMyMTkwNzI1NTgyOGI1YjNlOWIxOTQzLi42MDIwODYz ZDgzMDg0YjUzMDU5ODcxYTlkODZmYjViOTc2MzUyOTEwIDEwMDY0NAotLS0gYS9Tb3VyY2UvV1RG L3d0Zi9BdG9taWNzLmgKKysrIGIvU291cmNlL1dURi93dGYvQXRvbWljcy5oCkBAIC0yMzYsNiAr MjM2LDE2IEBAIGlubGluZSB2b2lkIHg4Nl9jcHVpZCgpCiAjaWYgT1MoV0lORE9XUykKICAgICBp bnQgaW5mb1s0XTsKICAgICBfX2NwdWlkKGluZm8sIDApOworI2VsaWYgQ1BVKFg4NikgJiYgZGVm aW5lZChfX1BJQ19fKSAmJiBfX0dOVUNfXyA8IDUKKyAgICBpbnRwdHJfdCBhID0gMCwgYiwgYywg ZDsKKyAgICBhc20gdm9sYXRpbGUoCisgICAgICAgICJwdXNobCAlJWVieDsiIC8vIHNhdmUgJWVi eAorICAgICAgICAiY3B1aWQ7IgorICAgICAgICAibW92bCAlJWVieCwgJTA7IiAvLyBzYXZlIHdo YXQgY3B1aWQgcHV0IGluICVlYnggaW50byB0aGUgZmlyc3Qgb3V0cHV0IChiKQorICAgICAgICAi cG9wbCAlJWVieDsiIC8vIHJlc3RvcmUgdGhlIG9sZCAlZWJ4IHZhbHVlCisgICAgICAgIDogIj1y IihiKSwgIithIihhKSwgIj1jIihjKSwgIj1kIihkKQorICAgICAgICA6CisgICAgICAgIDogIm1l bW9yeSIpOwogI2Vsc2UKICAgICBpbnRwdHJfdCBhID0gMCwgYiwgYywgZDsKICAgICBhc20gdm9s YXRpbGUoCg== 294401 2016-11-10 13:12:55 -0800 2016-11-15 13:09:01 -0800 Patch bug-164588-20161110220842.patch text/plain 1848 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjA4NTM4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IGJmZjllOGVlYzA4MTUzZGRhMDM1ZDc4 NTVmMTNhZGE2MjQ4MGE1NDcuLjhmNTg5NzJhNDJlMGU3OWRmMjM3YzAxZDVjMWJiNTU1OWYwYzQ4 MjQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjEgQEAKKzIwMTYtMTEtMTAgIENhcmxvcyBBbGJlcnRvIExvcGV6 IFBlcmV6ICA8Y2xvcGV6QGlnYWxpYS5jb20+CisKKyAgICAgICAgW0pTQ10gQnVpbGQgYnJva2Vu IGZvciAzMi1iaXQgeDg2IGFmdGVyIHIyMDgzMDYgd2l0aCBHQ0MgNC45CisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjQ1ODgKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBQcm92aWRlIGFzc2VtYmx5IGZvciBl eGVjdXRpbmcgdGhlIGNwdWlkIGluc3RydWN0aW9uIHdoZW4gY29tcGlsaW5nCisgICAgICAgIGlu IFBJQyBtb2RlIHdpdGggdGhlIEdDQyA0LjkgRUJYIG9uIDMyLWJpdCB4ODYuCisKKyAgICAgICAg Tm90ZSB0aGF0IHRoZSB2YWx1ZXMgcmV0dXJuZWQgYnkgY3B1aWQgaGVyZSBhcmUgbm90IHVzZWQu IFRoZSBwdXJwb3NlCisgICAgICAgIG9mIGNhbGxpbmcgdGhpcyBpbnN0cnVjdGlvbiBpcyB0byBm b3JjZSB0aGUgQ1BVIHRvIGNvbXBsZXRlIGFuZCBzeW5jCisgICAgICAgIGFueSBidWZmZXJlZCBt b2RpZmljYXRpb25zIG9uIHJlZ2lzdGVycywgbWVtb3J5IG9yIGZsYWdzIGJlZm9yZQorICAgICAg ICBmZXRjaGluZyBhbmQgZXhlY3V0aW5nIHRoZSBuZXh0IGluc3RydWN0aW9uLgorCisgICAgICAg ICogd3RmL0F0b21pY3MuaDoKKyAgICAgICAgKFdURjo6eDg2X2NwdWlkKToKKwogMjAxNi0xMS0w OSAgQWxleCBDaHJpc3RlbnNlbiAgPGFjaHJpc3RlbnNlbkB3ZWJraXQub3JnPgogCiAgICAgICAg IEFsbG93IFJlZlB0cnMgb2YgY29uc3QgVGhyZWFkU2FmZVJlZkNvdW50ZWQgdHlwZXMKZGlmZiAt LWdpdCBhL1NvdXJjZS9XVEYvd3RmL0F0b21pY3MuaCBiL1NvdXJjZS9XVEYvd3RmL0F0b21pY3Mu aAppbmRleCA5YjlhMmY3ODg3YTVmMzE5OWMyMTkwNzI1NTgyOGI1YjNlOWIxOTQzLi41MDIzYWIz NDU4YWU2OWY4YmY4MmE2OGNiODk0OWI1YTA1OTZmNjY1IDEwMDY0NAotLS0gYS9Tb3VyY2UvV1RG L3d0Zi9BdG9taWNzLmgKKysrIGIvU291cmNlL1dURi93dGYvQXRvbWljcy5oCkBAIC0yMzYsNiAr MjM2LDE2IEBAIGlubGluZSB2b2lkIHg4Nl9jcHVpZCgpCiAjaWYgT1MoV0lORE9XUykKICAgICBp bnQgaW5mb1s0XTsKICAgICBfX2NwdWlkKGluZm8sIDApOworI2VsaWYgQ1BVKFg4NikgJiYgZGVm aW5lZChfX1BJQ19fKSAmJiBDT01QSUxFUihHQ0MpICYmIF9fR05VQ19fIDwgNQorICAgIGludHB0 cl90IGEgPSAwLCBiLCBjLCBkOworICAgIGFzbSB2b2xhdGlsZSgKKyAgICAgICAgInB1c2hsICUl ZWJ4OyIgLy8gc2F2ZSAlZWJ4CisgICAgICAgICJjcHVpZDsiCisgICAgICAgICJtb3ZsICUlZWJ4 LCAlMDsiIC8vIHNhdmUgd2hhdCBjcHVpZCBwdXQgaW4gJWVieCBpbnRvIHRoZSBmaXJzdCBvdXRw dXQgKGIpCisgICAgICAgICJwb3BsICUlZWJ4OyIgLy8gcmVzdG9yZSB0aGUgb2xkICVlYnggdmFs dWUKKyAgICAgICAgOiAiPXIiKGIpLCAiK2EiKGEpLCAiPWMiKGMpLCAiPWQiKGQpCisgICAgICAg IDoKKyAgICAgICAgOiAibWVtb3J5Iik7CiAjZWxzZQogICAgIGludHB0cl90IGEgPSAwLCBiLCBj LCBkOwogICAgIGFzbSB2b2xhdGlsZSgK 294870 2016-11-15 13:09:21 -0800 2016-11-16 13:01:05 -0800 Patch bug-164588-20161115220918.patch text/plain 1917 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjA4NzQ4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDMwODdkNWI1NTA5NjMzMTE5MjI1NDVh NWU1NDliN2EyNGY4YTI4MDkuLjFkMmZhMzAwZDcxZjk0ZGU4YzhmZGM5MDVjOTAwMmU4OThkZjBi ODkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMjEgQEAKKzIwMTYtMTEtMTUgIENhcmxvcyBBbGJlcnRvIExvcGV6 IFBlcmV6ICA8Y2xvcGV6QGlnYWxpYS5jb20+CisKKyAgICAgICAgW0pTQ10gQnVpbGQgYnJva2Vu IGZvciAzMi1iaXQgeDg2IGFmdGVyIHIyMDgzMDYgd2l0aCBHQ0MgNC45CisgICAgICAgIGh0dHBz Oi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjQ1ODgKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBQcm92aWRlIGFzc2VtYmx5IGZvciBl eGVjdXRpbmcgdGhlIGNwdWlkIGluc3RydWN0aW9uIHdoZW4gY29tcGlsaW5nCisgICAgICAgIGlu IFBJQyBtb2RlIHdpdGggdGhlIEdDQyA0LjkgRUJYIG9uIDMyLWJpdCB4ODYuCisKKyAgICAgICAg Tm90ZSB0aGF0IHRoZSB2YWx1ZXMgcmV0dXJuZWQgYnkgY3B1aWQgaGVyZSBhcmUgbm90IHVzZWQu IFRoZSBwdXJwb3NlCisgICAgICAgIG9mIGNhbGxpbmcgdGhpcyBpbnN0cnVjdGlvbiBpcyB0byBm b3JjZSB0aGUgQ1BVIHRvIGNvbXBsZXRlIGFuZCBzeW5jCisgICAgICAgIGFueSBidWZmZXJlZCBt b2RpZmljYXRpb25zIG9uIHJlZ2lzdGVycywgbWVtb3J5IG9yIGZsYWdzIGJlZm9yZQorICAgICAg ICBmZXRjaGluZyBhbmQgZXhlY3V0aW5nIHRoZSBuZXh0IGluc3RydWN0aW9uLgorCisgICAgICAg ICogd3RmL0F0b21pY3MuaDoKKyAgICAgICAgKFdURjo6eDg2X2NwdWlkKToKKwogMjAxNi0xMS0x MSAgRmlsaXAgUGl6bG8gIDxmcGl6bG9AYXBwbGUuY29tPgogCiAgICAgICAgIFRoZSBHQyBzaG91 bGQgYmUgb3B0aW9uYWxseSBjb25jdXJyZW50IGFuZCBkaXNhYmxlZCBieSBkZWZhdWx0CmRpZmYg LS1naXQgYS9Tb3VyY2UvV1RGL3d0Zi9BdG9taWNzLmggYi9Tb3VyY2UvV1RGL3d0Zi9BdG9taWNz LmgKaW5kZXggNjg3ZmExNDBjOTE5ZWRlOTM0Y2YyNjQxMzQ3MDdmYjAwZGExMjhjNi4uNGE4ZWU0 OGU3NjIwYWViMTQ2YzM4M2Q2NzllNTJlZWViOTgxMWEwMyAxMDA2NDQKLS0tIGEvU291cmNlL1dU Ri93dGYvQXRvbWljcy5oCisrKyBiL1NvdXJjZS9XVEYvd3RmL0F0b21pY3MuaApAQCAtMjY2LDYg KzI2NiwxOCBAQCBpbmxpbmUgdm9pZCB4ODZfY3B1aWQoKQogI2lmIE9TKFdJTkRPV1MpCiAgICAg aW50IGluZm9bNF07CiAgICAgX19jcHVpZChpbmZvLCAwKTsKKyNlbGlmIENQVShYODYpCisgICAg Ly8gR0NDIDQuOSBvbiB4ODYgaW4gUElDIG1vZGUgY2FuJ3QgdXNlICVlYngsIHNvIHdlIGhhdmUg dG8gc2F2ZSBhbmQgcmVzdG9yZSBpdCBtYW51YWxseS4KKyAgICAvLyBCdXQgc2luY2Ugd2UgZG9u J3QgY2FyZSBhYm91dCB3aGF0IGNwdWlkIHJldHVybnMgKHdlIHVzZSBpdCBhcyBhIHNlcmlhbGl6 aW5nIGluc3RydWN0aW9uKSwKKyAgICAvLyB3ZSBjYW4gc2ltcGx5IHRocm93IGF3YXkgd2hhdCBj cHVpZCBwdXQgaW4gJWVieC4KKyAgICBpbnRwdHJfdCBhID0gMCwgYywgZDsKKyAgICBhc20gdm9s YXRpbGUoCisgICAgICAgICJwdXNobCAlJWVieFxuXHQiCisgICAgICAgICJjcHVpZFxuXHQiCisg ICAgICAgICJwb3BsICUlZWJ4XG5cdCIKKyAgICAgICAgOiAiK2EiKGEpLCAiPWMiKGMpLCAiPWQi KGQpCisgICAgICAgIDoKKyAgICAgICAgOiAibWVtb3J5Iik7CiAjZWxzZQogICAgIGludHB0cl90 IGEgPSAwLCBiLCBjLCBkOwogICAgIGFzbSB2b2xhdGlsZSgK