400538 2018-11-01 02:31:14 +0000 vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 2019-11-29 18:59:27 +0000 1 1 6 Developer tools valgrind vex 3.14 SVN Arch Linux Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=253657 NOR normal --- 0 alexhenrie24 jseward austinenglish dlehman25 dougvj eeknaak 0 oldest_to_newest 1805043 0 alexhenrie24 2018-11-01 02:31:14 +0000 When I try to use Valgrind to debug any 64-bit Windows program, I get the following error: vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 This is easily reproducible by running `valgrind --trace-children=yes wine notepad`. For what it's worth, I run Arch Linux and all packages are up-to-date. 1843993 1 jseward 2019-03-13 15:31:38 +0000 0x48 0xCF is IRETQ (return from interrupt) and it segfaults when run even natively (not on V) on my Fedora 29 box. So I'm kinda surprised that you expect it to work when running on V. But maybe I misunderstand what's going on here? My test case is int main ( void ) { __asm__ __volatile__(".byte 0x48, 0xCF" ::: "cc","memory"); return 0; } 1844056 2 dougvj 2019-03-13 20:43:03 +0000 IRETQ appears to be used by wine to start executing a CPU context. In normal operation this context is generated by the CPU when it is interrupted and pushed onto the stack, which is picked up by IRETQ when the interrupt is done being handled. Wine appears to generate this context on the stack itself so it's not using one generated by the CPU for IRETQ. Simply executing IRETQ without a valid CPU context on the stack will surely cause a segfault as the stack doesn't contain a valid instruction pointer and other CPU state. The segfault may even be caused by a stack underflow in this case, I am not sure. 1844057 3 dougvj 2019-03-13 20:45:58 +0000 See the wine source here for usage of IRETQ: https://github.com/wine-mirror/wine/blob/master/dlls/ntdll/signal_x86_64.c 1844124 4 alexhenrie24 2019-03-14 04:22:35 +0000 Wine has been using IRETQ since May 2009: https://source.winehq.org/git/wine.git/commitdiff/880d00fb43de924a3543b0ad53b5aaf0ad63d0cb The first reference I could find to IRETQ in Wine causing a problem with Valgrind was in January 2013: https://sourceforge.net/p/valgrind/mailman/message/30422124/ 1844509 5 118834 dougvj 2019-03-16 08:38:59 +0000 Created attachment 118834 IRETQ Test Case I went ahead and implemented a minimal test case which is attached. I confirmed the code runs fine on metal but chokes in valgrind producing a similar error message: unhandled instruction bytes: 0x48 0xCF 0xDE 0xAD 0xBE 0xEF 1844510 6 118834 dougvj 2019-03-16 08:54:48 +0000 Comment on attachment 118834 IRETQ Test Case >#include <stdio.h> >#include <stdlib.h> > >void return_from_iret() { > printf("Hello From IRETQ\n"); > exit(0); >} > > >int main() { > asm ( > "pushfq\n" > "movq 0(%%rsp), %%rbx\n" //rbx contains eflags > "popfq\n" > "subq $40, %%rsp\n" //Allocate our stack area for iret > "movq %%ss, %%rax\n" > "movq %%rax, 32(%%rsp)\n" //SS > "movq %%rsp, %%rax\n" > "movq %%rax, 24(%%rsp)\n" //SP > "movq %%rbx, 16(%%rsp)\n" //EFLAGS > "movq %%cs, %%rax\n" > "movq %%rax, 8(%%rsp)\n" //CS > "movq %0, 0(%%rsp)\n" //RIP > "iretq\n" > ".byte 0xDE, 0xAD, 0xBE, 0xEF\n" > : //no outputs > : "r" (return_from_iret) > : "rax", "rbx" //clobber list > ); > return 1; >} 1849774 7 austinenglish 2019-04-11 03:24:44 +0000 Okay, I can reproduce this, it needs a couple more valgrind arguments. # First, start a wine process (so that wineserver is running before valgrind starts): $ wine64 start /min winemine # Then, start notepad under valgrind: $ austin@laptop:~/src/valgrind$ valgrind --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64-preloader /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== preloader: Warning: failed to reserve range 0000000000110000-0000000068000000 ==2874== vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==2874== valgrind: Unrecognised instruction at address 0x7bc9bff3. ==2874== at 0x7BC9BFF3: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Your program just tried to execute an instruction that Valgrind ==2874== did not recognise. There are two possible reasons for this. ==2874== 1. Your program has a bug and erroneously jumped to a non-code ==2874== location. If you are running Memcheck and you just saw a ==2874== warning about a bad jump, it's probably your program's fault. ==2874== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2874== i.e. it's Valgrind's fault. If you think this is the case or ==2874== you are not sure, please let us know and we'll try to fix it. ==2874== Either way, Valgrind will now raise a SIGILL signal which will ==2874== probably kill your program. 005d:err:seh:segv_handler Got unexpected trap 0 ==2874== Invalid write of size 8 ==2874== at 0x7BC9BFF8: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== by 0x7BC9BFF2: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Address 0x7ffffe20f4b8 is in a rw- anonymous segment ==2874== 005d:err:seh:NtRaiseException Unhandled exception code c000001d flags 0 addr 0x7bc9bff3 ==2874== ==2874== HEAP SUMMARY: ==2874== in use at exit: 731,905 bytes in 6,501 blocks ==2874== total heap usage: 13,837 allocs, 7,336 frees, 2,963,926 bytes allocated ==2874== ==2874== LEAK SUMMARY: ==2874== definitely lost: 318 bytes in 2 blocks ==2874== indirectly lost: 0 bytes in 0 blocks ==2874== possibly lost: 0 bytes in 0 blocks ==2874== still reachable: 731,587 bytes in 6,499 blocks ==2874== suppressed: 0 bytes in 0 blocks ==2874== Rerun with --leak-check=full to see details of leaked memory ==2874== ==2874== For counts of detected and suppressed errors, rerun with: -v ==2874== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Tested with 3.15-rc1 / wine-4.5 1853769 8 119759 dlehman25 2019-05-01 05:43:03 +0000 Created attachment 119759 iretq implementation updated version of the iretq implementation i included in the tarball in https://bugs.kde.org/show_bug.cgi?id=253657 1868125 9 jseward 2019-07-10 14:54:18 +0000 (In reply to Daniel Lehman from comment #8) > Created attachment 119759 [details] > iretq implementation > > updated version of the iretq implementation i included in the tarball in > https://bugs.kde.org/show_bug.cgi?id=253657 Daniel, all, sorry to have been so slow looking at this. Thank you for the patch. The patch ignores the new values for %CS and %SS, which seems reasonable to me, given that Vex doesn't model segment registers on x86_64 anyway (per comment above dis_mov_S_E() in guest_amd64_toIR.c). However, afaics, the patch also ignores the new value for %rflags.d, which iirc is the string-operation direction flag. We do need to restore that in order that any pending string operations continue in the right direction, I think. See the implementation for POPF in that same file, for how to set it. The Intel docs for IRETQ have this in a couple of places: RETURN-TO-SAME-PRIVILEGE-LEVEL: (* PE = 1, RPL = CPL *) ... EFLAGS (CF, PF, AF, ZF, SF, TF, DF, OF, NT) ← tempEFLAGS; which is why I think at least D should be restored. I notice that Vex also models the ID and AC flags (see, again, the POPF implementation) but from the Intel docs it's not clear to me whether these also need to be restoired from 'tempEFLAGS' above. 1868863 10 121516 dlehman25 2019-07-15 02:34:50 +0000 Created attachment 121516 updated iretq implementation > Vex also models the ID and AC flags (see, again, the POPF implementation) > but from the Intel docs it's not clear to me whether these also need > to be restoired from 'tempEFLAGS' above from the docs, it does look like they need to be restored. using the attached iretq test case in a debugger, i can see that the ID and AC are saved across iretq > EFLAGS (CF, PF, AF, ZF, SF, TF, DF, OF, NT) ← tempEFLAGS; it doesn't look like VEX models certain flags like NT or TF > See the implementation for POPF in that same file, for how to set it the attached uses the code from popf. i retested with the latest wine 4.12.1 1875757 11 jseward 2019-08-19 14:09:58 +0000 Committed, e7dde4bc20bf57b4c1e25801f8462d1519c4fa41. Thanks for the patch. I took the liberty of adding an extra condition which disallows decoding if there is an 0x66, 0xF2 or 0xF3 prefix present, which I think should make it a little safer. 1875811 12 alexhenrie24 2019-08-19 17:08:03 +0000 Thank you Julian, having this patch committed is a big help to the Wine project! 1894022 13 tom 2019-11-29 18:59:27 +0000 *** Bug 414659 has been marked as a duplicate of this bug. *** 118834 2019-03-16 08:38:59 +0000 2019-03-16 08:38:59 +0000 IRETQ Test Case iretq_test_case.c text/x-csrc 810 dougvj I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KCnZvaWQgcmV0dXJuRnJvbUly ZXQoKSB7CiAgICBwcmludGYoIkhlbGxvIEZyb20gSVJFVFFcbiIpOwogICAgZXhpdCgwKTsKfQoK CmludCBtYWluKCkgewogICAgdm9pZCgqc3RhcnRfY29udGV4dCkodm9pZCkgPSByZXR1cm5Gcm9t SXJldDsKICAgIGFzbSAoCiAgICAgICAgInB1c2hmcVxuIgogICAgICAgICJtb3ZxIDAoJSVyc3Ap LCAlJXJieFxuIiAvL3JieCBjb250YWlucyBlZmxhZ3MKICAgICAgICAicG9wZnFcbiIKICAgICAg ICAic3VicSAkNDAsICAgJSVyc3BcbiIgLy9BbGxvY2F0ZSBvdXIgc3RhY2sgYXJlYSBmb3IgaXJl dAogICAgICAgICJtb3ZxICUlc3MsICAlJXJheFxuIgogICAgICAgICJtb3ZxICUlcmF4LCAzMigl JXJzcClcbiIgICAvL1NTCiAgICAgICAgIm1vdnEgJSVyc3AsICAlJXJheFxuIgogICAgICAgICJt b3ZxICUlcmF4LCAyNCglJXJzcClcbiIgLy9TUAogICAgICAgICJtb3ZxICUlcmJ4LCAxNiglJXJz cClcbiIgLy9FRkxBR1MKICAgICAgICAibW92cSAlJWNzLCAgJSVyYXhcbiIKICAgICAgICAibW92 cSAlJXJheCwgOCglJXJzcClcbiIgIC8vQ1MKICAgICAgICAibW92cSAlMCwgICAgMCglJXJzcClc biIgIC8vUklQCiAgICAgICAgImlyZXRxXG4iCiAgICAgICAgIi5ieXRlIDB4REUsIDB4QUQsIDB4 QkUsIDB4RUZcbiIKICAgICAgICA6IC8vbm8gb3V0cHV0cwogICAgICAgIDogInIiIChzdGFydF9j b250ZXh0KQogICAgICAgIDogInJheCIsICJyYngiIC8vY2xvYmJlciBsaXN0CiAgICApOwogICAg cmV0dXJuIDE7Cn0K 119759 2019-05-01 05:43:03 +0000 2019-07-15 02:34:50 +0000 iretq implementation 0001-amd64-Kludgey-64-bit-version-of-iret-implementation-fr.txt text/plain 2348 dlehman25 RnJvbSAwOTFkY2FiZjY2Zjk4MzRlYThkNzRmZmM3MmFlYTA5YTBjODc2NzhkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTGVobWFuIDxkbGVobWFuMjVAZ21haWwuY29tPgpE YXRlOiBNb24sIDE0IE1heSAyMDE4IDIzOjM3OjU1IC0wNzAwClN1YmplY3Q6IFtQQVRDSF0gYW1k NjQ6IEtsdWRnZXkgNjQtYml0IHZlcnNpb24gb2YgaXJldCBpbXBsZW1lbnRhdGlvbiBmcm9tCiBp Mzg2LgoKaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQwMDUzOAoKU2VlIGFs c286IGh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD0yNTM2NTcKU2lnbmVkLW9m Zi1ieTogRGFuaWVsIExlaG1hbiA8ZGxlaG1hbjI1QGdtYWlsLmNvbT4KLS0tCiBWRVgvcHJpdi9n dWVzdF9hbWQ2NF90b0lSLmMgfCAzNSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KwogMSBmaWxlIGNoYW5nZWQsIDM1IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9WRVgvcHJp di9ndWVzdF9hbWQ2NF90b0lSLmMgYi9WRVgvcHJpdi9ndWVzdF9hbWQ2NF90b0lSLmMKaW5kZXgg N2EyMGQ0NTIzLi42OGZjODg5MjQgMTAwNjQ0Ci0tLSBhL1ZFWC9wcml2L2d1ZXN0X2FtZDY0X3Rv SVIuYworKysgYi9WRVgvcHJpdi9ndWVzdF9hbWQ2NF90b0lSLmMKQEAgLTIxMDUyLDYgKzIxMDUy LDQxIEBAIExvbmcgZGlzX0VTQ19OT05FICgKICAgICAgIH0KICAgICAgIGdvdG8gZGVjb2RlX2Zh aWx1cmU7CiAKKyAgIGNhc2UgMHhDRjogLyogSVJFVCAqLworICAgICAgLyogTm90ZSwgdGhpcyBp cyBhbiBleHRyZW1lbHkga2x1ZGdleSBhbmQgbGltaXRlZCBpbXBsZW1lbnRhdGlvbiBvZiBpcmV0 CisgICAgICAgICBiYXNlZCBvbiB0aGUgZXh0cmVtZWx5IGtsdWRnZXkgYW5kIGxpbWl0ZWQgaW1w bGVtZW50YXRpb24gb2YgaXJldCBmb3IgeDg2CisgICAgICAgICAgICBwb3BxICVSSVA7IHBvcGwg JUNTOyBwb3BxICVSRkxBR1M7IHBvcHEgJVJTUDsgcG9wbCAlU1MKKyAgICAgICAgICVDUyBhbmQg JVNTIGFyZSBpZ25vcmVkICovCisgICAgICBpZiAoc3ogIT0gOCkgZ290byBkZWNvZGVfZmFpbHVy ZTsKKworICAgICAgdDEgPSBuZXdUZW1wKEl0eV9JNjQpOyAvKiBSU1AgKi8KKyAgICAgIHQyID0g bmV3VGVtcChJdHlfSTY0KTsgLyogbmV3IFJJUCAqLworICAgICAgLyogdDMgPSBuZXdUZW1wKEl0 eV9JMzIpOyAgbmV3IENTICovCisgICAgICB0NCA9IG5ld1RlbXAoSXR5X0k2NCk7IC8qIG5ldyBS RkxBR1MgKi8KKyAgICAgIHQ1ID0gbmV3VGVtcChJdHlfSTY0KTsgLyogbmV3IFJTUCAqLworICAg ICAgLyogdDYgPSBuZXdUZW1wKEl0eV9JMzIpOyAgbmV3IFNTICovCisKKyAgICAgIGFzc2lnbih0 MSwgZ2V0SVJlZzY0KFJfUlNQKSk7CisgICAgICBhc3NpZ24odDIsIGxvYWRMRShJdHlfSTY0LCBi aW5vcChJb3BfQWRkNjQsbWtleHByKHQxKSxta1U2NCgwKSkpKTsKKyAgICAgIC8qIGFzc2lnbih0 MywgbG9hZExFKEl0eV9JMzIsIGJpbm9wKElvcF9BZGQ2NCxta2V4cHIodDEpLG1rVTY0KDgpKSkp OyAqLworICAgICAgYXNzaWduKHQ0LCBsb2FkTEUoSXR5X0k2NCwgYmlub3AoSW9wX0FkZDY0LG1r ZXhwcih0MSksbWtVNjQoMTYpKSkpOworICAgICAgYXNzaWduKHQ1LCBsb2FkTEUoSXR5X0k2NCwg Ymlub3AoSW9wX0FkZDY0LG1rZXhwcih0MSksbWtVNjQoMjQpKSkpOworICAgICAgLyogYXNzaWdu KHQ2LCBsb2FkTEUoSXR5X0kzMiwgYmlub3AoSW9wX0FkZDY0LG1rZXhwcih0MSksbWtVNjQoMzIp KSkpOyAqLworCisgICAgICAvKiBzZXQgJVJGTEFHUyAqLworICAgICAgc3RtdCggSVJTdG10X1B1 dCggT0ZGQl9DQ19PUCwgICBta1U2NChBTUQ2NEdfQ0NfT1BfQ09QWSkgKSk7CisgICAgICBzdG10 KCBJUlN0bXRfUHV0KCBPRkZCX0NDX0RFUDEsIG1rZXhwcih0NCkgKSk7CisgICAgICBzdG10KCBJ UlN0bXRfUHV0KCBPRkZCX0NDX0RFUDIsIG1rVTY0KDApICkpOworICAgICAgc3RtdCggSVJTdG10 X1B1dCggT0ZGQl9DQ19OREVQLCBta1U2NCgwKSApKTsKKworICAgICAgLyogc2V0IG5ldyBzdGFj ayAqLworICAgICAgcHV0SVJlZzY0KFJfUlNQLCBta2V4cHIodDUpKTsKKworICAgICAgLyogZ290 byBuZXcgUklQIHZhbHVlICovCisgICAgICBqbXBfdHJlZyhkcmVzLCBJamtfUmV0LCB0Mik7Cisg ICAgICBESVAoImlyZXQgKHZlcnkga2x1ZGdleSlcbiIpOworICAgICAgcmV0dXJuIGRlbHRhOwor CiAgICBjYXNlIDB4RDA6IHsgLyogR3JwMiAxLEViICovCiAgICAgICBCb29sIGRlY29kZV9PSyA9 IFRydWU7CiAgICAgICBpZiAoaGF2ZUYyb3JGMyhwZngpKSBnb3RvIGRlY29kZV9mYWlsdXJlOwot LSAKMi4xNy4xCgo= 121516 2019-07-15 02:34:50 +0000 2019-07-15 02:34:50 +0000 updated iretq implementation 0001-amd64-Kludgey-64-bit-version-of-iret-implementation-fr.txt text/plain 4073 dlehman25 RnJvbSA3N2E3NGM0ZTE5MGNlNTBhYWU4NDI5NzM2OGMwYmFmOTYzNzYzNDAyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTGVobWFuIDxkbGVobWFuMjVAZ21haWwuY29tPgpE YXRlOiBNb24sIDE0IE1heSAyMDE4IDIzOjM3OjU1IC0wNzAwClN1YmplY3Q6IFtQQVRDSF0gYW1k NjQ6IEtsdWRnZXkgNjQtYml0IHZlcnNpb24gb2YgaXJldCBpbXBsZW1lbnRhdGlvbiBmcm9tCiBp Mzg2LgoKaHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQwMDUzOAoKU2VlIGFs c286IGh0dHBzOi8vYnVncy5rZGUub3JnL3Nob3dfYnVnLmNnaT9pZD0yNTM2NTcKU2lnbmVkLW9m Zi1ieTogRGFuaWVsIExlaG1hbiA8ZGxlaG1hbjI1QGdtYWlsLmNvbT4KCnYyOgotIHVzZWQgZmxh ZyBzZXR0aW5nIGNvZGUgZnJvbSBwb3BmCgpTaWduZWQtb2ZmLWJ5OiBEYW5pZWwgTGVobWFuIDxk bGVobWFuMjVAZ21haWwuY29tPgotLS0KIFZFWC9wcml2L2d1ZXN0X2FtZDY0X3RvSVIuYyB8IDgx ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA4 MSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvVkVYL3ByaXYvZ3Vlc3RfYW1kNjRfdG9JUi5j IGIvVkVYL3ByaXYvZ3Vlc3RfYW1kNjRfdG9JUi5jCmluZGV4IDk2ZGVlMzgxOC4uZGM5MDhlOTEy IDEwMDY0NAotLS0gYS9WRVgvcHJpdi9ndWVzdF9hbWQ2NF90b0lSLmMKKysrIGIvVkVYL3ByaXYv Z3Vlc3RfYW1kNjRfdG9JUi5jCkBAIC0yMTA1MCw2ICsyMTA1MCw4NyBAQCBMb25nIGRpc19FU0Nf Tk9ORSAoCiAgICAgICB9CiAgICAgICBnb3RvIGRlY29kZV9mYWlsdXJlOwogCisgICBjYXNlIDB4 Q0Y6IC8qIElSRVQgKi8KKyAgICAgIC8qIE5vdGUsIHRoaXMgaXMgYW4gZXh0cmVtZWx5IGtsdWRn ZXkgYW5kIGxpbWl0ZWQgaW1wbGVtZW50YXRpb24gb2YgaXJldAorICAgICAgICAgYmFzZWQgb24g dGhlIGV4dHJlbWVseSBrbHVkZ2V5IGFuZCBsaW1pdGVkIGltcGxlbWVudGF0aW9uIG9mIGlyZXQg Zm9yIHg4NgorICAgICAgICAgICAgcG9wcSAlUklQOyBwb3BsICVDUzsgcG9wcSAlUkZMQUdTOyBw b3BxICVSU1A7IHBvcGwgJVNTCisgICAgICAgICAlQ1MgYW5kICVTUyBhcmUgaWdub3JlZCAqLwor ICAgICAgaWYgKHN6ICE9IDgpIGdvdG8gZGVjb2RlX2ZhaWx1cmU7CisKKyAgICAgIHQxID0gbmV3 VGVtcChJdHlfSTY0KTsgLyogUlNQICovCisgICAgICB0MiA9IG5ld1RlbXAoSXR5X0k2NCk7IC8q IG5ldyBSSVAgKi8KKyAgICAgIC8qIHQzID0gbmV3VGVtcChJdHlfSTMyKTsgIG5ldyBDUyAqLwor ICAgICAgdDQgPSBuZXdUZW1wKEl0eV9JNjQpOyAvKiBuZXcgUkZMQUdTICovCisgICAgICB0NSA9 IG5ld1RlbXAoSXR5X0k2NCk7IC8qIG5ldyBSU1AgKi8KKyAgICAgIC8qIHQ2ID0gbmV3VGVtcChJ dHlfSTMyKTsgIG5ldyBTUyAqLworCisgICAgICBhc3NpZ24odDEsIGdldElSZWc2NChSX1JTUCkp OworICAgICAgYXNzaWduKHQyLCBsb2FkTEUoSXR5X0k2NCwgYmlub3AoSW9wX0FkZDY0LG1rZXhw cih0MSksbWtVNjQoMCkpKSk7CisgICAgICAvKiBhc3NpZ24odDMsIGxvYWRMRShJdHlfSTMyLCBi aW5vcChJb3BfQWRkNjQsbWtleHByKHQxKSxta1U2NCg4KSkpKTsgKi8KKyAgICAgIGFzc2lnbih0 NCwgbG9hZExFKEl0eV9JNjQsIGJpbm9wKElvcF9BZGQ2NCxta2V4cHIodDEpLG1rVTY0KDE2KSkp KTsKKyAgICAgIGFzc2lnbih0NSwgbG9hZExFKEl0eV9JNjQsIGJpbm9wKElvcF9BZGQ2NCxta2V4 cHIodDEpLG1rVTY0KDI0KSkpKTsKKyAgICAgIC8qIGFzc2lnbih0NiwgbG9hZExFKEl0eV9JMzIs IGJpbm9wKElvcF9BZGQ2NCxta2V4cHIodDEpLG1rVTY0KDMyKSkpKTsgKi8KKworICAgICAgLyog c2V0ICVSRkxBR1MgKi8KKyAgICAgIHN0bXQoIElSU3RtdF9QdXQoIE9GRkJfQ0NfT1AsICAgbWtV NjQoQU1ENjRHX0NDX09QX0NPUFkpICkpOworICAgICAgc3RtdCggSVJTdG10X1B1dCggT0ZGQl9D Q19OREVQLCBta1U2NCgwKSApKTsKKyAgICAgIHN0bXQoIElSU3RtdF9QdXQoIE9GRkJfQ0NfREVQ MiwgbWtVNjQoMCkgKSk7CisgICAgICBzdG10KCBJUlN0bXRfUHV0KCBPRkZCX0NDX0RFUDEsCisg ICAgICAgICAgICAgICAgICAgICAgICBiaW5vcChJb3BfQW5kNjQsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBta2V4cHIodDQpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWtVNjQoIEFNRDY0R19DQ19NQVNLX0MgfCBBTUQ2NEdfQ0NfTUFTS19QCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCBBTUQ2NEdfQ0NfTUFTS19BIHwgQU1ENjRHX0NDX01B U0tfWgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQU1ENjRHX0NDX01B U0tfU3wgQU1ENjRHX0NDX01BU0tfTyApCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICkK KyAgICAgICAgICAgICAgICAgICAgICAgKQorICAgICAgICAgICk7CisKKyAgICAgIC8qIEFsc28g bmVlZCB0byBzZXQgdGhlIEQgZmxhZywgd2hpY2ggaXMgaGVsZCBpbiBiaXQgMTAgb2YgdDQuCisg ICAgICAgICBJZiB6ZXJvLCBwdXQgMSBpbiBPRkZCX0RGTEFHLCBlbHNlIC0xIGluIE9GRkJfREZM QUcuICovCisgICAgICBzdG10KCBJUlN0bXRfUHV0KAorICAgICAgICAgICAgICAgT0ZGQl9ERkxB RywKKyAgICAgICAgICAgICAgIElSRXhwcl9JVEUoCisgICAgICAgICAgICAgICAgICB1bm9wKElv cF82NHRvMSwKKyAgICAgICAgICAgICAgICAgICAgICAgYmlub3AoSW9wX0FuZDY0LAorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBiaW5vcChJb3BfU2hyNjQsIG1rZXhwcih0NCksIG1rVTgo MTApKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWtVNjQoMSkpKSwKKyAgICAgICAg ICAgICAgICAgIG1rVTY0KDB4RkZGRkZGRkZGRkZGRkZGRlVMTCksCisgICAgICAgICAgICAgICAg ICBta1U2NCgxKSkpCisgICAgICAgICAgKTsKKworICAgICAgLyogQW5kIHNldCB0aGUgSUQgZmxh ZyAqLworICAgICAgc3RtdCggSVJTdG10X1B1dCgKKyAgICAgICAgICAgICAgIE9GRkJfSURGTEFH LAorICAgICAgICAgICAgICAgSVJFeHByX0lURSgKKyAgICAgICAgICAgICAgICAgIHVub3AoSW9w XzY0dG8xLAorICAgICAgICAgICAgICAgICAgICAgICBiaW5vcChJb3BfQW5kNjQsCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGJpbm9wKElvcF9TaHI2NCwgbWtleHByKHQ0KSwgbWtVOCgy MSkpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICBta1U2NCgxKSkpLAorICAgICAgICAg ICAgICAgICAgbWtVNjQoMSksCisgICAgICAgICAgICAgICAgICBta1U2NCgwKSkpCisgICAgICAg ICAgKTsKKworICAgICAgLyogQW5kIHNldCB0aGUgQUMgZmxhZyB0b28gKi8KKyAgICAgIHN0bXQo IElSU3RtdF9QdXQoCisgICAgICAgICAgICAgICBPRkZCX0FDRkxBRywKKyAgICAgICAgICAgICAg IElSRXhwcl9JVEUoCisgICAgICAgICAgICAgICAgICB1bm9wKElvcF82NHRvMSwKKyAgICAgICAg ICAgICAgICAgICAgICAgYmlub3AoSW9wX0FuZDY0LAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBiaW5vcChJb3BfU2hyNjQsIG1rZXhwcih0NCksIG1rVTgoMTgpKSwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbWtVNjQoMSkpKSwKKyAgICAgICAgICAgICAgICAgIG1rVTY0KDEp LAorICAgICAgICAgICAgICAgICAgbWtVNjQoMCkpKQorICAgICAgICAgICk7CisKKworICAgICAg Lyogc2V0IG5ldyBzdGFjayAqLworICAgICAgcHV0SVJlZzY0KFJfUlNQLCBta2V4cHIodDUpKTsK KworICAgICAgLyogZ290byBuZXcgUklQIHZhbHVlICovCisgICAgICBqbXBfdHJlZyhkcmVzLCBJ amtfUmV0LCB0Mik7CisgICAgICBESVAoImlyZXQgKHZlcnkga2x1ZGdleSlcbiIpOworICAgICAg cmV0dXJuIGRlbHRhOworCiAgICBjYXNlIDB4RDA6IHsgLyogR3JwMiAxLEViICovCiAgICAgICBC b29sIGRlY29kZV9PSyA9IFRydWU7CiAgICAgICBpZiAoaGF2ZUYyb3JGMyhwZngpKSBnb3RvIGRl Y29kZV9mYWlsdXJlOwotLSAKMi4xNy4xCgo=