172767 2017-05-31 12:08:19 -0700 [JSC][ARMv6] Fix ARMv6 JIT support 2017-07-12 11:15:24 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified NEW P2 Normal --- 108645 172765 1 ticaiolima ticaiolima buildbot fpizlo guijemont jacob.bramley+webkit keith_miller mark.lam msaboff ossy saam oldest_to_newest 1314254 0 ticaiolima 2017-05-31 12:08:19 -0700 ... 1314269 1 311619 ticaiolima 2017-05-31 12:30:52 -0700 Created attachment 311619 Patch 1314271 2 buildbot 2017-05-31 12:32:37 -0700 Attachment 311619 did not pass style-queue: ERROR: Source/JavaScriptCore/assembler/ARMAssembler.h:218: enum members should use InterCaps with an initial capital letter or initial 'k' for C-style enums. [readability/enum_casing] [4] Total errors found: 1 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style. 1316531 3 311619 mark.lam 2017-06-07 10:28:23 -0700 Comment on attachment 311619 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311619&action=review > Source/JavaScriptCore/assembler/ARMAssembler.h:218 > + // mcr 15, 0, r6, cr7, cr10, {5} > + ARM6_MEMFENCE = 0xee076fba, I think this may not be correct. Someone who knows ARM better should take a closer look. Here's why: 1. The instruction you're replacing is DMBSY. The spec for DMBSY (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/BABDFABI.html) says: "DMB acts as a data memory barrier. It ensures that all explicit memory accesses that appear, in program order, before the DMB instruction are completed before any explicit memory accesses that appear, in program order, after the DMB instruction. DMB does not affect the ordering or execution of instructions that do not access memory." Specifically, it ensures that memory access are completed in program order. 2. You're replacing it with "mcr 15, 0, r6, cr7, cr10, {5}". The spec for MCR (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html) says: "... As such, DMB ensures the apparent order of the explicit memory operations before and after the DMB instruction, but does not ensure the completion of those memory operations." I suspect what you really want is a "Data Synchronization Barrier", but I'm not certain. Someone who knows better needs to review this. Also, you picked r6 for the <Rd> argument in the instruction. What's the reason for this? It's not clear from the spec what <Rd> is for in terms of the "Data Memory Barrier" or "Data Synchronization Barrier". Maybe it doesn't matter, but someone who knows traditional ARM better should review this. > Source/JavaScriptCore/jit/RegisterSet.cpp:163 > +#elif CPU(ARM) > + result.set(ARMRegisters::r4); > + result.set(ARMRegisters::r5); > + result.set(ARMRegisters::r6); > + result.set(ARMRegisters::r7); > + result.set(ARMRegisters::r8); > + result.set(ARMRegisters::r9); > + result.set(ARMRegisters::r10); There's already a section for CPU(ARM_TRADITIONAL) above. This is not needed. Please remove and remember to update your ChangeLog. Also, I think this set is incomplete. https://stackoverflow.com/questions/261419/arm-to-c-calling-convention-registers-to-save says the callee saved regs are r4-r8, r9 (possibly), and r10-r11. Your new set is missing r11. 1319124 4 311619 ticaiolima 2017-06-14 08:16:47 -0700 Comment on attachment 311619 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311619&action=review Thank you for the review >> Source/JavaScriptCore/assembler/ARMAssembler.h:218 >> + ARM6_MEMFENCE = 0xee076fba, > > I think this may not be correct. Someone who knows ARM better should take a closer look. Here's why: > > 1. The instruction you're replacing is DMBSY. > The spec for DMBSY (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/BABDFABI.html) says: > "DMB acts as a data memory barrier. It ensures that all explicit memory accesses that appear, in program order, before the DMB instruction are completed before any explicit memory accesses that appear, in program order, after the DMB instruction. DMB does not affect the ordering or execution of instructions that do not access memory." > Specifically, it ensures that memory access are completed in program order. > > 2. You're replacing it with "mcr 15, 0, r6, cr7, cr10, {5}". > The spec for MCR (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html) says: > "... As such, DMB ensures the apparent order of the explicit memory operations before and after the DMB instruction, but does not ensure the completion of those memory operations." > > I suspect what you really want is a "Data Synchronization Barrier", but I'm not certain. Someone who knows better needs to review this. > > Also, you picked r6 for the <Rd> argument in the instruction. What's the reason for this? It's not clear from the spec what <Rd> is for in terms of the "Data Memory Barrier" or "Data Synchronization Barrier". Maybe it doesn't matter, but someone who knows traditional ARM better should review this. Yes. I was researching about your questions and I'm not able to give you 100% of certain about them, so I just pinged the original authors of the Patch and they are going to give clarifications here soon. One thing that I noticed between DSB and DMB in ARM11 is that instructions after DSB don't execute until it finishes. If I didn't misunderstood, "dmb sy"doesn't impose it and the code is more performant in practice. Following the ARM spec, It seems that we probably don't have a "dmb sy" equivalent instruction into ARM11 and we will probably need to choose which one is better. >> Source/JavaScriptCore/jit/RegisterSet.cpp:163 >> + result.set(ARMRegisters::r10); > > There's already a section for CPU(ARM_TRADITIONAL) above. This is not needed. Please remove and remember to update your ChangeLog. > > Also, I think this set is incomplete. https://stackoverflow.com/questions/261419/arm-to-c-calling-convention-registers-to-save says the callee saved regs are r4-r8, r9 (possibly), and r10-r11. Your new set is missing r11. Ok. 1321653 5 311619 guijemont 2017-06-21 15:27:56 -0700 Comment on attachment 311619 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311619&action=review >>> Source/JavaScriptCore/assembler/ARMAssembler.h:218 >>> + ARM6_MEMFENCE = 0xee076fba, >> >> I think this may not be correct. Someone who knows ARM better should take a closer look. Here's why: >> >> 1. The instruction you're replacing is DMBSY. >> The spec for DMBSY (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/BABDFABI.html) says: >> "DMB acts as a data memory barrier. It ensures that all explicit memory accesses that appear, in program order, before the DMB instruction are completed before any explicit memory accesses that appear, in program order, after the DMB instruction. DMB does not affect the ordering or execution of instructions that do not access memory." >> Specifically, it ensures that memory access are completed in program order. >> >> 2. You're replacing it with "mcr 15, 0, r6, cr7, cr10, {5}". >> The spec for MCR (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html) says: >> "... As such, DMB ensures the apparent order of the explicit memory operations before and after the DMB instruction, but does not ensure the completion of those memory operations." >> >> I suspect what you really want is a "Data Synchronization Barrier", but I'm not certain. Someone who knows better needs to review this. >> >> Also, you picked r6 for the <Rd> argument in the instruction. What's the reason for this? It's not clear from the spec what <Rd> is for in terms of the "Data Memory Barrier" or "Data Synchronization Barrier". Maybe it doesn't matter, but someone who knows traditional ARM better should review this. > > Yes. I was researching about your questions and I'm not able to give you 100% of certain about them, so I just pinged the original authors of the Patch and they are going to give clarifications here soon. > > One thing that I noticed between DSB and DMB in ARM11 is that instructions after DSB don't execute until it finishes. If I didn't misunderstood, "dmb sy"doesn't impose it and the code is more performant in practice. Following the ARM spec, It seems that we probably don't have a "dmb sy" equivalent instruction into ARM11 and we will probably need to choose which one is better. Original author of the patch here, sorry for the delay. Regarding difference of DMB/DSB: I think the wording "but does not ensure the completion of those memory operations." means that the previous memory operations are not guaranteed to finish before the MCR finishes, but it provides a guarantee that they will be finished before other memory accesses after the MCR. My impression is that this second guarantee is enough for our needs, but I cannot claim I understand all the (present and future) uses of memoryBarrier in JavaScriptCore, so it could be good to have somebody else (not sure whom) weigh in on what are the needs here. Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. Regarding the use of $r6, my understanding from the documentation is that it is not modified, and I could confirm that on my device with gdb, so I just picked a random register. 1322835 6 ticaiolima 2017-06-26 08:07:29 -0700 Hi all, here are some updates that I've got in a new round of research. I've found the following reference of ARM11: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Babhejba.html "The purpose of the Data Memory Barrier operation is to ensure that all outstanding explicit memory transactions complete before any following explicit memory transactions begin. This ensures that data in memory is up to date before any memory transaction that depends on it." Also, we can check the last ARMv6-M Arch Reference (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0419d/DDI0419D_armv6m_arm.pdf) the following statement in page A3-59: "The DMB instruction is a data memory barrier. DMB exhibits the following behavior: - All explicit memory accesses by instructions occurring in program order before this instruction are globally observed before any explicit memory accesses because of instructions occurring in program order after this instruction are observed. - The DMB instruction has no effect on the ordering of other instructions executing on the processor. As such, DMB ensures the apparent order of the explicit memory operations before and after the instruction, without ensuring their completion. For details on the DMB instruction, see DMB on page A6-121." In the same manual, we can find at page A3-57: "For all memory, a read or write is defined to be complete when it is globally observed: - A branch predictor maintenance operation is defined to be complete when the effects of operation are globally observed." About the statement: "DMB ensures the apparent order of the explicit memory operations before and after the instruction, without ensuring their completion." I understand that the "dmb" doesn't wait until the completion of memory access. The instruction that assures that is "dsb", since it's completion just happens when the memory access before it are complete. We can check that in http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/CHDDGICF.html Given that, I think we really want "mcr 15, 0, <rd>, cr7, cr10, {5}" in ARMv6 since it's equivalent of ARMv7 "dmb sy;". PS.: The manual I'm pointing in ARM11 is the manual of the processor I'm testing the ARMv6 support. I could find the "dmb sy" instruction in ARMv6-M reference, however it isn't present in the ARM11 reference. Who could we ask this kind of question that is ARM related? 1325348 7 311619 fpizlo 2017-07-03 18:01:58 -0700 Comment on attachment 311619 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311619&action=review >>>> Source/JavaScriptCore/assembler/ARMAssembler.h:218 >>>> + ARM6_MEMFENCE = 0xee076fba, >>> >>> I think this may not be correct. Someone who knows ARM better should take a closer look. Here's why: >>> >>> 1. The instruction you're replacing is DMBSY. >>> The spec for DMBSY (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/BABDFABI.html) says: >>> "DMB acts as a data memory barrier. It ensures that all explicit memory accesses that appear, in program order, before the DMB instruction are completed before any explicit memory accesses that appear, in program order, after the DMB instruction. DMB does not affect the ordering or execution of instructions that do not access memory." >>> Specifically, it ensures that memory access are completed in program order. >>> >>> 2. You're replacing it with "mcr 15, 0, r6, cr7, cr10, {5}". >>> The spec for MCR (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html) says: >>> "... As such, DMB ensures the apparent order of the explicit memory operations before and after the DMB instruction, but does not ensure the completion of those memory operations." >>> >>> I suspect what you really want is a "Data Synchronization Barrier", but I'm not certain. Someone who knows better needs to review this. >>> >>> Also, you picked r6 for the <Rd> argument in the instruction. What's the reason for this? It's not clear from the spec what <Rd> is for in terms of the "Data Memory Barrier" or "Data Synchronization Barrier". Maybe it doesn't matter, but someone who knows traditional ARM better should review this. >> >> Yes. I was researching about your questions and I'm not able to give you 100% of certain about them, so I just pinged the original authors of the Patch and they are going to give clarifications here soon. >> >> One thing that I noticed between DSB and DMB in ARM11 is that instructions after DSB don't execute until it finishes. If I didn't misunderstood, "dmb sy"doesn't impose it and the code is more performant in practice. Following the ARM spec, It seems that we probably don't have a "dmb sy" equivalent instruction into ARM11 and we will probably need to choose which one is better. > > Original author of the patch here, sorry for the delay. > > Regarding difference of DMB/DSB: I think the wording "but does not ensure the completion of those memory operations." means that the previous memory operations are not guaranteed to finish before the MCR finishes, but it provides a guarantee that they will be finished before other memory accesses after the MCR. My impression is that this second guarantee is enough for our needs, but I cannot claim I understand all the (present and future) uses of memoryBarrier in JavaScriptCore, so it could be good to have somebody else (not sure whom) weigh in on what are the needs here. > > Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. > > Regarding the use of $r6, my understanding from the documentation is that it is not modified, and I could confirm that on my device with gdb, so I just picked a random register. Hi everyone, I'm probably the best point of reference for the meaning of the various fences in JSC. MacroAssembler::memoryFence() is supposed to mean an acqrel fence: all accesses from before the acqrel will indeed happen before all of the accesses after the acqrel. This is indeed weaker than the DSB fence, which also forces the entire execution of those prior instructions to finish before any execution of those after it start. DSB is probably meant for what we call the WTF::crossModifyingCodeFence(), in <wtf/Atomics.h>. Here are two code snippets that I read in order to reach the conclusion that MacroAssembler::memoryFence() means acqrel. I never remember this stuff, but I do remember where to look. In MacroAssemblerARM64.h, we have: // We take memoryFence to mean acqrel. This has acqrel semantics on ARM64. void memoryFence() { m_assembler.dmbISH(); } Look at that great comment! I like looking at the ARM64 assembler because our memory model is essentially the philosophical superset of x86-TSO and ARM64 memory models. Most of the hard stuff is because of ARM64, not x86. So, typically, you can find out the most about crazy memory model stuff by just seeing what the ARM64 assembler does. Another place to look is B3LowerToAir. Note that Air instructions are almost always MacroAssembler method names, so "MemoryFence" means MacroAssembler::memoryFence(). case Fence: { FenceValue* fence = m_value->as<FenceValue>(); if (!fence->write && !fence->read) return; if (!fence->write) { // A fence that reads but does not write is for protecting motion of stores. append(StoreFence); return; } if (!fence->read) { // A fence that writes but does not read is for protecting motion of loads. append(LoadFence); return; } append(MemoryFence); return; } This is the one mention of MemoryFence. Here we see that we select MemoryFence from B3::Fence when we want to protect the motion of both reads and writes. Sounds about right and DMB does that. So, yeah, this should be DMB. 1325377 8 314551 ticaiolima 2017-07-03 20:53:36 -0700 Created attachment 314551 Patch 1325378 9 buildbot 2017-07-03 20:54:47 -0700 Attachment 314551 did not pass style-queue: ERROR: Source/JavaScriptCore/assembler/ARMAssembler.h:218: enum members should use InterCaps with an initial capital letter or initial 'k' for C-style enums. [readability/enum_casing] [4] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style. 1326261 10 311619 mark.lam 2017-07-06 17:32:05 -0700 Comment on attachment 311619 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=311619&action=review >>>>> Source/JavaScriptCore/assembler/ARMAssembler.h:218 >>>>> + ARM6_MEMFENCE = 0xee076fba, >>>> >>>> I think this may not be correct. Someone who knows ARM better should take a closer look. Here's why: >>>> >>>> 1. The instruction you're replacing is DMBSY. >>>> The spec for DMBSY (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/BABDFABI.html) says: >>>> "DMB acts as a data memory barrier. It ensures that all explicit memory accesses that appear, in program order, before the DMB instruction are completed before any explicit memory accesses that appear, in program order, after the DMB instruction. DMB does not affect the ordering or execution of instructions that do not access memory." >>>> Specifically, it ensures that memory access are completed in program order. >>>> >>>> 2. You're replacing it with "mcr 15, 0, r6, cr7, cr10, {5}". >>>> The spec for MCR (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html) says: >>>> "... As such, DMB ensures the apparent order of the explicit memory operations before and after the DMB instruction, but does not ensure the completion of those memory operations." >>>> >>>> I suspect what you really want is a "Data Synchronization Barrier", but I'm not certain. Someone who knows better needs to review this. >>>> >>>> Also, you picked r6 for the <Rd> argument in the instruction. What's the reason for this? It's not clear from the spec what <Rd> is for in terms of the "Data Memory Barrier" or "Data Synchronization Barrier". Maybe it doesn't matter, but someone who knows traditional ARM better should review this. >>> >>> Yes. I was researching about your questions and I'm not able to give you 100% of certain about them, so I just pinged the original authors of the Patch and they are going to give clarifications here soon. >>> >>> One thing that I noticed between DSB and DMB in ARM11 is that instructions after DSB don't execute until it finishes. If I didn't misunderstood, "dmb sy"doesn't impose it and the code is more performant in practice. Following the ARM spec, It seems that we probably don't have a "dmb sy" equivalent instruction into ARM11 and we will probably need to choose which one is better. >> >> Original author of the patch here, sorry for the delay. >> >> Regarding difference of DMB/DSB: I think the wording "but does not ensure the completion of those memory operations." means that the previous memory operations are not guaranteed to finish before the MCR finishes, but it provides a guarantee that they will be finished before other memory accesses after the MCR. My impression is that this second guarantee is enough for our needs, but I cannot claim I understand all the (present and future) uses of memoryBarrier in JavaScriptCore, so it could be good to have somebody else (not sure whom) weigh in on what are the needs here. >> >> Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. >> >> Regarding the use of $r6, my understanding from the documentation is that it is not modified, and I could confirm that on my device with gdb, so I just picked a random register. > > Hi everyone, > > I'm probably the best point of reference for the meaning of the various fences in JSC. MacroAssembler::memoryFence() is supposed to mean an acqrel fence: all accesses from before the acqrel will indeed happen before all of the accesses after the acqrel. This is indeed weaker than the DSB fence, which also forces the entire execution of those prior instructions to finish before any execution of those after it start. DSB is probably meant for what we call the WTF::crossModifyingCodeFence(), in <wtf/Atomics.h>. > > Here are two code snippets that I read in order to reach the conclusion that MacroAssembler::memoryFence() means acqrel. I never remember this stuff, but I do remember where to look. > > In MacroAssemblerARM64.h, we have: > > // We take memoryFence to mean acqrel. This has acqrel semantics on ARM64. > void memoryFence() > { > m_assembler.dmbISH(); > } > > Look at that great comment! I like looking at the ARM64 assembler because our memory model is essentially the philosophical superset of x86-TSO and ARM64 memory models. Most of the hard stuff is because of ARM64, not x86. So, typically, you can find out the most about crazy memory model stuff by just seeing what the ARM64 assembler does. > > Another place to look is B3LowerToAir. Note that Air instructions are almost always MacroAssembler method names, so "MemoryFence" means MacroAssembler::memoryFence(). > > case Fence: { > FenceValue* fence = m_value->as<FenceValue>(); > if (!fence->write && !fence->read) > return; > if (!fence->write) { > // A fence that reads but does not write is for protecting motion of stores. > append(StoreFence); > return; > } > if (!fence->read) { > // A fence that writes but does not read is for protecting motion of loads. > append(LoadFence); > return; > } > append(MemoryFence); > return; > } > > This is the one mention of MemoryFence. Here we see that we select MemoryFence from B3::Fence when we want to protect the motion of both reads and writes. Sounds about right and DMB does that. > > So, yeah, this should be DMB. @Guillaume, can you point me to the documentation (url) about the use of <Rd> in the mcr instruction for DMB? You're passing r6. r6 may not be modified, but is it supposed to provide some sort of input value? I have not yet seen ARM documentation that explains what the expectation is (other than <Rd> cannot be PC). 1327491 11 jacob.bramley+webkit 2017-07-11 08:51:37 -0700 Hello all, I hope you don't mind me chipping in. I think most of the issues in the discussion were resolved but it looks like there were one or two unanswered questions which I might be able to help with. I've had to interpret the barrier documentation enough times that some of it has actually stuck. @Filip, based on your description of memoryFence, your conclusion that DMB is appropriate is correct. I wonder if the SY (system) shareability domain is necessary, though, or if something like ISH (inner shareable) would suffice. This depends on the system design, and how memoryFence is used. > @Guillaume, can you point me to the documentation (url) about the use of > <Rd> in the mcr instruction for DMB? You're passing r6. r6 may not be > modified, but is it supposed to provide some sort of input value? I have > not yet seen ARM documentation that explains what the expectation is (other > than <Rd> cannot be PC). The `mcr` instruction takes a register (as an input) but for the DMB operation it is ignored (and doesn't have to be initialised to anything in particular). This is stated at the bottom of page B6-1945 of the ARMv7-AR ARM (edition 0406C.c): https://developer.arm.com/docs/ddi0406/latest/arm-architecture-reference-manual-armv7-a-and-armv7-r-edition @Caio: > Also, we can check the last ARMv6-M Arch Reference (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0419d/DDI0419D_armv6m_arm.pdf) the following statement in page A3-59 Although I think the wording you quoted still applies, note that the ARMv6-M document refers only to M-class (microcontroller) systems with, no MMU and suchlike. It doesn't refer to the likes of ARM11. At one time I think there was an "ARMv6" reference manual but now it's all covered in the ARMv7-AR one that I mentioned above. Also note that the ARMv6 MCR-based DMB performs the same operation as the ARMv7 DMB. The wording is different in the various different documents but the operation is the same either way. @Guillaume: > Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. Actually the register has no meaning to DSB (nor for ISB) as far as I'm aware. I'm curious, though: where did you find that information? Thanks, Jacob 1327543 12 mark.lam 2017-07-11 10:04:11 -0700 (In reply to Jacob Bramley from comment #11) > The `mcr` instruction takes a register (as an input) but for the DMB > operation it is ignored (and doesn't have to be initialised to anything in > particular). This is stated at the bottom of page B6-1945 of the ARMv7-AR > ARM (edition 0406C.c): > https://developer.arm.com/docs/ddi0406/latest/arm-architecture-reference- > manual-armv7-a-and-armv7-r-edition Jacob, thanks. 1327548 13 314551 mark.lam 2017-07-11 10:19:09 -0700 Comment on attachment 314551 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314551&action=review I think this patch is almost ready now that we have the spec so that we know it's doing the right thing. Please apply the changes. r- for now. Thanks. > Source/JavaScriptCore/ChangeLog:8 > + Original author is Guillaume Emont. Any specific reason why Guillaume isn't posting the patch himself? > Source/JavaScriptCore/assembler/ARMAssembler.h:217 > + // mcr 15, 0, r6, cr7, cr10, {5} I think it's helpful to add a comment here saying: // The r6 argument register is ignored by this operation. Hence, it does not need to be initialized. // See section B6.2.2 in page B6-1945 of https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf. It also seems quite arbitrary and out of left field to choose r6 (as if there's some special reason for its choice). Why not just choose r0? > Source/JavaScriptCore/assembler/ARMAssembler.h:218 > + ARM6_MEMFENCE = 0xee076fba, The spec for the in section B6.2.2 page B6-1946 of https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf says: "CP15DMB, Data Memory Barrier operation In ARMv7, use the DMB instruction to perform a Data Memory Barrier, see DMB on page A8-378. The deprecated CP15 c7 encoding for a Data Memory Barrier is an MCR instruction with <opc1> set to 0, <CRn> set to c7, <CRm> set to c10, and <opc2> set to 5. This operation performs the full system barrier performed by the DMB instruction." Note the part that says "full system barrier performed by the DMB instruction". Hence, let's rename ARM6_MEMFENCE as ARM6_DMB_SY. > Source/JavaScriptCore/assembler/ARMAssembler.h:733 > - void dmbSY() > + void memoryFence() Let's undo this. > Source/JavaScriptCore/assembler/ARMAssembler.h:738 > + m_buffer.putInt(ARM6_MEMFENCE); Rename to ARM6_DMB_SY. > Source/JavaScriptCore/assembler/MacroAssemblerARM.h:1489 > - m_assembler.dmbSY(); > + m_assembler.memoryFence(); Undo this. 1327741 14 314551 guijemont 2017-07-11 14:28:08 -0700 Comment on attachment 314551 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314551&action=review >> Source/JavaScriptCore/ChangeLog:8 >> + Original author is Guillaume Emont. > > Any specific reason why Guillaume isn't posting the patch himself? I initially made this as a dirty downstream patch, Caio is kindly cleaning it up and sending it here. The main motivation for this is to help him understand this code. A secondary motivation is that I am busy with other things and without his help, who knows when I would have found the time. >> Source/JavaScriptCore/assembler/ARMAssembler.h:217 >> + // mcr 15, 0, r6, cr7, cr10, {5} > > I think it's helpful to add a comment here saying: > // The r6 argument register is ignored by this operation. Hence, it does not need to be initialized. > // See section B6.2.2 in page B6-1945 of https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf. > > It also seems quite arbitrary and out of left field to choose r6 (as if there's some special reason for its choice). Why not just choose r0? My bad, I think I indeed chose $r6 arbitrarily. I think $r0 should be fine. 1327750 15 guijemont 2017-07-11 14:36:26 -0700 (In reply to Jacob Bramley from comment #11) > > @Guillaume: > > Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. > > Actually the register has no meaning to DSB (nor for ISB) as far as I'm > aware. I'm curious, though: where did you find that information? I have an old pdf lying around tiled "ARM Architecture Reference Manual" that seems to be from 2005. It has a table on page B6-21 and B6-22 describing the mcr 15 cr7 operations. for (c10, 4), it says "SBZ" in the data field. I did not understand what that means. I just did some more research in the document, and it seems to mean "Should Be Zero". I think that therefore we definitely want to use $r0 instead of $r6. 1327757 16 mark.lam 2017-07-11 14:48:27 -0700 (In reply to Guillaume Emont from comment #15) > (In reply to Jacob Bramley from comment #11) > > > > @Guillaume: > > > Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. > > > > Actually the register has no meaning to DSB (nor for ISB) as far as I'm > > aware. I'm curious, though: where did you find that information? > > I have an old pdf lying around tiled "ARM Architecture > Reference Manual" that seems to be from 2005. It has a table on page B6-21 > and B6-22 describing the mcr 15 cr7 operations. for (c10, 4), it says "SBZ" > in the data field. I did not understand what that means. I just did some > more research in the document, and it seems to mean "Should Be Zero". I > think that therefore we definitely want to use $r0 instead of $r6. The documentation isn't very clear about what SBZ means but I quite sure it doesn't means using r0. I think I read somewhere that SBZ implies that the input should have a zero value. Regardless, that is irrelevant here. The docs that Jacob point to is clear on the fact that the Rd argument register is ignored. So, r0 or r6 is fine. I just thought r0 is better because using r6 implies more purpose than it has. 1327817 17 ticaiolima 2017-07-11 16:17:08 -0700 @Jacob Thanks for the support here. Do you mind answer another question we discussed in the mailing list? Is there any ARMv6 processor that doesn't support the "mcr" operations? The problem here is because if the support is limited to some family of chips, our solution here isn't enough. 1327991 18 jacob.bramley+webkit 2017-07-12 03:42:04 -0700 (In reply to Mark Lam from comment #16) > (In reply to Guillaume Emont from comment #15) > > [...] > > > > I have an old pdf lying around tiled "ARM Architecture > > Reference Manual" that seems to be from 2005. It has a table on page B6-21 > > and B6-22 describing the mcr 15 cr7 operations. for (c10, 4), it says "SBZ" > > in the data field. I did not understand what that means. I just did some > > more research in the document, and it seems to mean "Should Be Zero". I > > think that therefore we definitely want to use $r0 instead of $r6. > > The documentation isn't very clear about what SBZ means but I quite sure it > doesn't means using r0. I think I read somewhere that SBZ implies that the > input should have a zero value. Regardless, that is irrelevant here. The > docs that Jacob point to is clear on the fact that the Rd argument register > is ignored. So, r0 or r6 is fine. I just thought r0 is better because > using r6 implies more purpose than it has. I think I've found that table (in document 0100I), and I interpret it the same way that you do. I would speculate that the SBZ specification was relaxed for ARMv7, and then applied retrospectively based on real implementations of ARMv6. In any case, the ARMv7-AR document I linked to is the latest official documentation for ARMv6 so I would prefer the explanation in that one. (In reply to Caio Lima from comment #17) > @Jacob > > Thanks for the support here. Do you mind answer another question we > discussed in the mailing list? > Is there any ARMv6 processor that doesn't support the "mcr" operations? The > problem here is because if the support is limited to some family of chips, > our solution here isn't enough. As far as I'm aware, all ARMv6 processors support these `mcr` operations. If that were not the case, the document would typically refer to something like "ARMv6K". Also note that the ARMv6 barriers were deprecated in ARMv7, and privileged code can deny access to them, so on newer architectures you may have problems if they are used in some lowest-common-supported-platform situation. Thanks, Jacob 1328137 19 mark.lam 2017-07-12 11:15:24 -0700 (In reply to Mark Lam from comment #16) > (In reply to Guillaume Emont from comment #15) > > (In reply to Jacob Bramley from comment #11) > > > > > > @Guillaume: > > > > Also, we do have a Data Synchronisation Barrier similar to DMB SY: it's the same instruction, but with cr7, cr10, {4}, though in that case I think the register passed has a meaning, which I don't fully understand. > > > > > > Actually the register has no meaning to DSB (nor for ISB) as far as I'm > > > aware. I'm curious, though: where did you find that information? > > > > I have an old pdf lying around tiled "ARM Architecture > > Reference Manual" that seems to be from 2005. It has a table on page B6-21 > > and B6-22 describing the mcr 15 cr7 operations. for (c10, 4), it says "SBZ" > > in the data field. I did not understand what that means. I just did some > > more research in the document, and it seems to mean "Should Be Zero". I > > think that therefore we definitely want to use $r0 instead of $r6. > > The documentation isn't very clear about what SBZ means but I quite sure it > doesn't means using r0. I think I read somewhere that SBZ implies that the > input should have a zero value. Regardless, that is irrelevant here. The > docs that Jacob point to is clear on the fact that the Rd argument register > is ignored. So, r0 or r6 is fine. I just thought r0 is better because > using r6 implies more purpose than it has. @Guillaume, I apologize. You were right: if the doc says SBZ, then the field should be 0. In the register field, this means r0. That said, I think the latest document is clear that the register value doesn't matter (except that it cannot be r15/pc). But it also doesn't hurt to set it to r0. Thanks. 311619 2017-05-31 12:30:52 -0700 2017-07-03 20:53:31 -0700 Patch bug-172767-20170531163051.patch text/plain 4652 ticaiolima U3VidmVyc2lvbiBSZXZpc2lvbjogMjE3NjEwCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCBk OWYyYzRmZWIwNGMwYzljM2EyZmU3N2FjZmEwNWU0ZTQ5MGQ4MDMxLi5hNTRhYWRmNzYzZWM2MTdk N2E3OWM3NWIxZmI2NTk2OWE2MDg1NTE5IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwyNyBAQAorMjAxNy0wNS0zMSAgQ2FpbyBMaW1hICA8dGljYWlvbGltYUBnbWFpbC5jb20+ CisKKyAgICAgICAgW0pTQ11bQVJNdjZdIEZpeCBBUk12NiBKSVQgc3VwcG9ydAorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTcyNzY3CisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgSW4gdGhpcyBwYXRjaCB3ZSBh cmUgY2hhbmdpbmcgc29tZSBKSVQgcGFydHMgdG8gY29tcGlsZSB0byBBUk02CisgICAgICAgIGFy Y2hpdGVjdHVyZS4gVGhlIGNoYW5nZXMgd2VyZToKKworICAgICAgICAtIE1lbW9yeSBmZW5jZSBz dXBwb3J0IHRvIEFSTXY2CisgICAgICAgIC0gQWxpZ24gY29uZmlndXJhdGlvbiBpbnRvIGNvZGUg c2VnbWVudHMKKyAgICAgICAgLSBVcGRhdGVkIGNhbGxlZVNhdmVSZWdpc3RlcnMgbGlzdAorCisg ICAgICAgICogYXNzZW1ibGVyL0FSTUFzc2VtYmxlci5oOgorICAgICAgICAoSlNDOjpBUk1Bc3Nl bWJsZXI6Om1lbW9yeUZlbmNlKToKKyAgICAgICAgKEpTQzo6QVJNQXNzZW1ibGVyOjpkbWJTWSk6 IERlbGV0ZWQuCisgICAgICAgICogYXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmNwcDoKKyAg ICAgICAgKiBhc3NlbWJsZXIvTWFjcm9Bc3NlbWJsZXJBUk0uaDoKKyAgICAgICAgKEpTQzo6TWFj cm9Bc3NlbWJsZXJBUk06Om1lbW9yeUZlbmNlKToKKyAgICAgICAgKiBqaXQvSklUT3BlcmF0aW9u cy5jcHA6CisgICAgICAgICogaml0L1JlZ2lzdGVyU2V0LmNwcDoKKyAgICAgICAgKEpTQzo6UmVn aXN0ZXJTZXQ6OmNhbGxlZVNhdmVSZWdpc3RlcnMpOgorCiAyMDE3LTA1LTMxICBLZWl0aCBNaWxs ZXIgIDxrZWl0aF9taWxsZXJAYXBwbGUuY29tPgogCiAgICAgICAgIEZpeCBsZWFrIGluIFByb21p c2VEZWZlcnJlZFRpbWVyCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYXNzZW1i bGVyL0FSTUFzc2VtYmxlci5oIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9BUk1B c3NlbWJsZXIuaAppbmRleCA5MWNlMGIyOWRhMmRlNGU4YTdhYjg2OTJlYjJhODg3YjkxOWJhOGE5 Li5hYWQwODExMWI1NTZkOTI2MDZiZTdhNmM5MTU4MjY5NWY1YmIxNDRmIDEwMDY0NAotLS0gYS9T b3VyY2UvSmF2YVNjcmlwdENvcmUvYXNzZW1ibGVyL0FSTUFzc2VtYmxlci5oCisrKyBiL1NvdXJj ZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvQVJNQXNzZW1ibGVyLmgKQEAgLTIxMyw2ICsyMTMs OSBAQCBuYW1lc3BhY2UgSlNDIHsKICNpZiBXVEZfQVJNX0FSQ0hfQVRfTEVBU1QoNykKICAgICAg ICAgICAgIE1PVlcgPSAweDAzMDAwMDAwLAogICAgICAgICAgICAgTU9WVCA9IDB4MDM0MDAwMDAs CisjZWxzZQorICAgICAgICAgICAgLy8gbWNyICAgICAxNSwgMCwgcjYsIGNyNywgY3IxMCwgezV9 CisgICAgICAgICAgICBBUk02X01FTUZFTkNFID0gMHhlZTA3NmZiYSwKICNlbmRpZgogICAgICAg ICAgICAgTk9QID0gMHhlMWEwMDAwMCwKICAgICAgICAgICAgIERNQl9TWSA9IDB4ZjU3ZmYwNWYs CkBAIC03MjcsOSArNzMwLDEzIEBAIG5hbWVzcGFjZSBKU0MgewogICAgICAgICAgICAgICAgICpw dHIrKyA9IGluc247CiAgICAgICAgIH0KIAotICAgICAgICB2b2lkIGRtYlNZKCkKKyAgICAgICAg dm9pZCBtZW1vcnlGZW5jZSgpCiAgICAgICAgIHsKKyNpZiBXVEZfQVJNX0FSQ0hfQVRfTEVBU1Qo NykKICAgICAgICAgICAgIG1fYnVmZmVyLnB1dEludChETUJfU1kpOworI2Vsc2UKKyAgICAgICAg ICAgIG1fYnVmZmVyLnB1dEludChBUk02X01FTUZFTkNFKTsKKyNlbmRpZgogICAgICAgICB9CiAK ICAgICAgICAgdm9pZCBkbWJJU0hTVCgpCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvYXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmNwcCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9hc3NlbWJsZXIvTWFjcm9Bc3NlbWJsZXJBUk0uY3BwCmluZGV4IGU1MDllYjQ1NTVhYTJhMTEx NzBlMzExZGUzNjU4ODYyMWIxMmFmZTUuLmEzNjI3OTdhYjRiZDgyM2FiNDU2YTA2MDYwYzE5MGI4 YTU2MTU4YWIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvTWFj cm9Bc3NlbWJsZXJBUk0uY3BwCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIv TWFjcm9Bc3NlbWJsZXJBUk0uY3BwCkBAIC0yMDgsNiArMjA4LDcgQEAgQ09NUElMRV9BU1NFUlQo IShQUk9CRV9BTElHTkVEX1NJWkUgJiAweGYpLCBQcm9iZUNvbnRleHRfYWxpZ25lZF9zaXplX29m ZnNldF9zaG8KIAogYXNtICgKICAgICAiLnRleHQiICJcbiIKKyAgICAiLmFsaWduIDIiICJcbiIK ICAgICAiLmdsb2JsICIgU1lNQk9MX1NUUklORyhjdGlNYXNtUHJvYmVUcmFtcG9saW5lKSAiXG4i CiAgICAgSElERV9TWU1CT0woY3RpTWFzbVByb2JlVHJhbXBvbGluZSkgIlxuIgogICAgIElOTElO RV9BUk1fRlVOQ1RJT04oY3RpTWFzbVByb2JlVHJhbXBvbGluZSkgIlxuIgpkaWZmIC0tZ2l0IGEv U291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fzc2VtYmxlckFSTS5oIGIvU291 cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fzc2VtYmxlckFSTS5oCmluZGV4IGRi ZTNjMjVjMDIxOGRlM2I4MjA0YTNjNzJlNTBkOWZhZjkyNTNjZDAuLjIwYWI0YjA4ZmNiOGZlMTg3 ZmEwYTVhOTBhZTFlZjQ3MTNkYWMxMDQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9hc3NlbWJsZXIvTWFjcm9Bc3NlbWJsZXJBUk0uaAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvYXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmgKQEAgLTE0ODAsNyArMTQ4MCw3IEBAIHB1 YmxpYzoKIAogICAgIHZvaWQgbWVtb3J5RmVuY2UoKQogICAgIHsKLSAgICAgICAgbV9hc3NlbWJs ZXIuZG1iU1koKTsKKyAgICAgICAgbV9hc3NlbWJsZXIubWVtb3J5RmVuY2UoKTsKICAgICB9CiAK ICAgICB2b2lkIHN0b3JlRmVuY2UoKQpkaWZmIC0tZ2l0IGEvU291cmNlL0phdmFTY3JpcHRDb3Jl L2ppdC9KSVRPcGVyYXRpb25zLmNwcCBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklUT3Bl cmF0aW9ucy5jcHAKaW5kZXggNGE0YTJlYjU0ZTM3ZGNiMTU5YjBjMmUyYWRjYjE1NmNmZmU2ZmY4 ZS4uZmQ5NTUzNjcxNjM3ODljYWQ0MzE0NDZlZTg1YzJhMDViMWFiNDIxNiAxMDA2NDQKLS0tIGEv U291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRPcGVyYXRpb25zLmNwcAorKysgYi9Tb3VyY2Uv SmF2YVNjcmlwdENvcmUvaml0L0pJVE9wZXJhdGlvbnMuY3BwCkBAIC0yODA2LDYgKzI4MDYsNyBA QCBTWU1CT0xfU1RSSU5HKGdldEhvc3RDYWxsUmV0dXJuVmFsdWUpICI6IiAiXG4iCiAjZWxpZiBD T01QSUxFUihHQ0NfT1JfQ0xBTkcpICYmIENQVShBUk1fVFJBRElUSU9OQUwpCiBhc20gKAogIi50 ZXh0IiAiXG4iCisiLmFsaWduIDIiICJcbiIKICIuZ2xvYmwgIiBTWU1CT0xfU1RSSU5HKGdldEhv c3RDYWxsUmV0dXJuVmFsdWUpICJcbiIKIEhJREVfU1lNQk9MKGdldEhvc3RDYWxsUmV0dXJuVmFs dWUpICJcbiIKIElOTElORV9BUk1fRlVOQ1RJT04oZ2V0SG9zdENhbGxSZXR1cm5WYWx1ZSkKZGlm ZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvUmVnaXN0ZXJTZXQuY3BwIGIvU291 cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9SZWdpc3RlclNldC5jcHAKaW5kZXggZTZlNzc0MWNmNjBl ZWRmNWFjOTVjNWM0ZmJjNjIxOGY0Nzg5ZTU4Yy4uNTE0MDM1YWY4NDU5YWQ5Y2U3OGZjZTg0NDM2 NDU1NWRhZjI0OGY0OSAxMDA2NDQKLS0tIGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9SZWdp c3RlclNldC5jcHAKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9SZWdpc3RlclNldC5j cHAKQEAgLTE1Myw2ICsxNTMsMTQgQEAgUmVnaXN0ZXJTZXQgUmVnaXN0ZXJTZXQ6OmNhbGxlZVNh dmVSZWdpc3RlcnMoKQogICAgICAgICByZWcgPSBzdGF0aWNfY2FzdDxBUk02NFJlZ2lzdGVyczo6 RlBSZWdpc3RlcklEPihyZWcgKyAxKSkKICAgICAgICAgcmVzdWx0LnNldChyZWcpOwogI2VsaWYg Q1BVKE1JUFMpCisjZWxpZiBDUFUoQVJNKQorICAgIHJlc3VsdC5zZXQoQVJNUmVnaXN0ZXJzOjpy NCk7CisgICAgcmVzdWx0LnNldChBUk1SZWdpc3RlcnM6OnI1KTsKKyAgICByZXN1bHQuc2V0KEFS TVJlZ2lzdGVyczo6cjYpOworICAgIHJlc3VsdC5zZXQoQVJNUmVnaXN0ZXJzOjpyNyk7CisgICAg cmVzdWx0LnNldChBUk1SZWdpc3RlcnM6OnI4KTsKKyAgICByZXN1bHQuc2V0KEFSTVJlZ2lzdGVy czo6cjkpOworICAgIHJlc3VsdC5zZXQoQVJNUmVnaXN0ZXJzOjpyMTApOwogI2Vsc2UKICAgICBV TlJFQUNIQUJMRV9GT1JfUExBVEZPUk0oKTsKICNlbmRpZgo= 314551 2017-07-03 20:53:36 -0700 2017-07-11 10:19:09 -0700 Patch bug-172767-20170704005334.patch text/plain 3854 ticaiolima U3VidmVyc2lvbiBSZXZpc2lvbjogMjE5MTExCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA5 YzQ3YTk1ODhhNGY1OTEyNTkyMjllNDA0MjBmN2U0NzAxOTEwNTBhLi5iMzdiY2I0ZjA2NGRmZjdi ZTk1Nzk3Y2ZkZTUwOTc1MjliNWQ0NjRiIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs MyArMSwyNSBAQAorMjAxNy0wNy0wNCAgQ2FpbyBMaW1hICA8dGljYWlvbGltYUBnbWFpbC5jb20+ CisKKyAgICAgICAgW0pTQ11bQVJNdjZdIEZpeCBBUk12NiBKSVQgc3VwcG9ydAorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTcyNzY3CisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgT3JpZ2luYWwgYXV0aG9yIGlz IEd1aWxsYXVtZSBFbW9udC4KKyAgICAgICAgSW4gdGhpcyBwYXRjaCB3ZSBhcmUgY2hhbmdpbmcg c29tZSBKSVQgcGFydHMgdG8gY29tcGlsZSB0byBBUk02CisgICAgICAgIGFyY2hpdGVjdHVyZS4g VGhlIGNoYW5nZXMgd2VyZToKKworICAgICAgICAtIE1lbW9yeSBmZW5jZSAoRE1CKSBzdXBwb3J0 IHRvIEFSTXY2CisgICAgICAgIC0gQWxpZ24gY29uZmlndXJhdGlvbiBpbnRvIGNvZGUgc2VnbWVu dHMKKworICAgICAgICAqIGFzc2VtYmxlci9BUk1Bc3NlbWJsZXIuaDoKKyAgICAgICAgKEpTQzo6 QVJNQXNzZW1ibGVyOjptZW1vcnlGZW5jZSk6CisgICAgICAgIChKU0M6OkFSTUFzc2VtYmxlcjo6 ZG1iU1kpOiBEZWxldGVkLgorICAgICAgICAqIGFzc2VtYmxlci9NYWNyb0Fzc2VtYmxlckFSTS5j cHA6CisgICAgICAgICogYXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmg6CisgICAgICAgIChK U0M6Ok1hY3JvQXNzZW1ibGVyQVJNOjptZW1vcnlGZW5jZSk6CisgICAgICAgICogaml0L0pJVE9w ZXJhdGlvbnMuY3BwOgorCiAyMDE3LTA3LTAzICBTYWFtIEJhcmF0aSAgPHNiYXJhdGlAYXBwbGUu Y29tPgogCiAgICAgICAgIERGR0J5dGVjb2RlUGFyc2VyIG9wX3RvX3RoaXMgZG9lcyBub3QgYWNj ZXNzIHRoZSBjb3JyZWN0IGluc3RydWN0aW9uIG9mZnNldCBmb3IgdG8gdGhpcyBzdGF0dXMKZGlm ZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvQVJNQXNzZW1ibGVyLmgg Yi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvYXNzZW1ibGVyL0FSTUFzc2VtYmxlci5oCmluZGV4IDQ4 ZTExMDE3MjQ0ZGRjZjdmYjEyNzIwYThiMWQ4NTliYjdlYWU5ZWIuLmJmNjMxODJiOWQ3OTY3OGI3 MDI3NTE1ZDIyODE4MGVjYjljMDMyYTAgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9hc3NlbWJsZXIvQVJNQXNzZW1ibGVyLmgKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fz c2VtYmxlci9BUk1Bc3NlbWJsZXIuaApAQCAtMjEzLDYgKzIxMyw5IEBAIG5hbWVzcGFjZSBKU0Mg ewogI2lmIFdURl9BUk1fQVJDSF9BVF9MRUFTVCg3KQogICAgICAgICAgICAgTU9WVyA9IDB4MDMw MDAwMDAsCiAgICAgICAgICAgICBNT1ZUID0gMHgwMzQwMDAwMCwKKyNlbHNlCisgICAgICAgICAg ICAvLyBtY3IgICAgIDE1LCAwLCByNiwgY3I3LCBjcjEwLCB7NX0KKyAgICAgICAgICAgIEFSTTZf TUVNRkVOQ0UgPSAweGVlMDc2ZmJhLAogI2VuZGlmCiAgICAgICAgICAgICBOT1AgPSAweGUxYTAw MDAwLAogICAgICAgICAgICAgRE1CX1NZID0gMHhmNTdmZjA1ZiwKQEAgLTcyNyw5ICs3MzAsMTMg QEAgbmFtZXNwYWNlIEpTQyB7CiAgICAgICAgICAgICAgICAgKnB0cisrID0gaW5zbjsKICAgICAg ICAgfQogCi0gICAgICAgIHZvaWQgZG1iU1koKQorICAgICAgICB2b2lkIG1lbW9yeUZlbmNlKCkK ICAgICAgICAgeworI2lmIFdURl9BUk1fQVJDSF9BVF9MRUFTVCg3KQogICAgICAgICAgICAgbV9i dWZmZXIucHV0SW50KERNQl9TWSk7CisjZWxzZQorICAgICAgICAgICAgbV9idWZmZXIucHV0SW50 KEFSTTZfTUVNRkVOQ0UpOworI2VuZGlmCiAgICAgICAgIH0KIAogICAgICAgICB2b2lkIGRtYklT SFNUKCkKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvTWFjcm9B c3NlbWJsZXJBUk0uY3BwIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fz c2VtYmxlckFSTS5jcHAKaW5kZXggZTUwOWViNDU1NWFhMmExMTE3MGUzMTFkZTM2NTg4NjIxYjEy YWZlNS4uYTM2Mjc5N2FiNGJkODIzYWI0NTZhMDYwNjBjMTkwYjhhNTYxNThhYiAxMDA2NDQKLS0t IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fzc2VtYmxlckFSTS5jcHAK KysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fzc2VtYmxlckFSTS5j cHAKQEAgLTIwOCw2ICsyMDgsNyBAQCBDT01QSUxFX0FTU0VSVCghKFBST0JFX0FMSUdORURfU0la RSAmIDB4ZiksIFByb2JlQ29udGV4dF9hbGlnbmVkX3NpemVfb2Zmc2V0X3NobwogCiBhc20gKAog ICAgICIudGV4dCIgIlxuIgorICAgICIuYWxpZ24gMiIgIlxuIgogICAgICIuZ2xvYmwgIiBTWU1C T0xfU1RSSU5HKGN0aU1hc21Qcm9iZVRyYW1wb2xpbmUpICJcbiIKICAgICBISURFX1NZTUJPTChj dGlNYXNtUHJvYmVUcmFtcG9saW5lKSAiXG4iCiAgICAgSU5MSU5FX0FSTV9GVU5DVElPTihjdGlN YXNtUHJvYmVUcmFtcG9saW5lKSAiXG4iCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvYXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmggYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUv YXNzZW1ibGVyL01hY3JvQXNzZW1ibGVyQVJNLmgKaW5kZXggMmI4MGQyNDdmOTdhNTAzZDRkNWY0 NWNkOTg1MmZjMjQyOTIxZWJhMy4uZjgzODhkZmI4NmYyMDIyM2E4NWIwNDlmM2Q3OTVkODNmMTg5 ZmI0MyAxMDA2NDQKLS0tIGEvU291cmNlL0phdmFTY3JpcHRDb3JlL2Fzc2VtYmxlci9NYWNyb0Fz c2VtYmxlckFSTS5oCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvTWFjcm9B c3NlbWJsZXJBUk0uaApAQCAtMTQ4Niw3ICsxNDg2LDcgQEAgcHVibGljOgogCiAgICAgdm9pZCBt ZW1vcnlGZW5jZSgpCiAgICAgewotICAgICAgICBtX2Fzc2VtYmxlci5kbWJTWSgpOworICAgICAg ICBtX2Fzc2VtYmxlci5tZW1vcnlGZW5jZSgpOwogICAgIH0KIAogICAgIHZvaWQgc3RvcmVGZW5j ZSgpCmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvaml0L0pJVE9wZXJhdGlvbnMu Y3BwIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRPcGVyYXRpb25zLmNwcAppbmRleCAx MWNjODZkZTI4NmNlNzg0MWZlN2RlODExODNlYmRkNDA3NTBhNWM5Li45Zjk2NjE5OGU3OWUwYzNk Y2EyMThlNmUzMWI3NjRjYzgyYmUzZDMzIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv cmUvaml0L0pJVE9wZXJhdGlvbnMuY3BwCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQv SklUT3BlcmF0aW9ucy5jcHAKQEAgLTI4MDgsNiArMjgwOCw3IEBAIFNZTUJPTF9TVFJJTkcoZ2V0 SG9zdENhbGxSZXR1cm5WYWx1ZSkgIjoiICJcbiIKICNlbGlmIENPTVBJTEVSKEdDQ19PUl9DTEFO RykgJiYgQ1BVKEFSTV9UUkFESVRJT05BTCkKIGFzbSAoCiAiLnRleHQiICJcbiIKKyIuYWxpZ24g MiIgIlxuIgogIi5nbG9ibCAiIFNZTUJPTF9TVFJJTkcoZ2V0SG9zdENhbGxSZXR1cm5WYWx1ZSkg IlxuIgogSElERV9TWU1CT0woZ2V0SG9zdENhbGxSZXR1cm5WYWx1ZSkgIlxuIgogSU5MSU5FX0FS TV9GVU5DVElPTihnZXRIb3N0Q2FsbFJldHVyblZhbHVlKQo=