You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
|
2
(1) |
3
|
|
4
|
5
(1) |
6
(2) |
7
(1) |
8
(1) |
9
(2) |
10
|
|
11
|
12
|
13
(6) |
14
(4) |
15
(1) |
16
(4) |
17
(2) |
|
18
(1) |
19
(8) |
20
(8) |
21
(2) |
22
(3) |
23
(3) |
24
|
|
25
|
26
|
27
(1) |
28
|
29
|
30
|
31
(2) |
|
From: Philippe W. <phi...@sk...> - 2019-08-19 22:38:28
|
On Mon, 2019-08-19 at 23:31 +0200, Philippe Waroquiers wrote: > Note that it just took me now about 1 minute and 5 lines of code to reproduce it > in Ada (but I guess it can be done in whatever language: it is enough to just > produce a very large BSS). > > So, valgrind error message is correctly pointing at the problem of very large bss > (as was already determined in 2017 IIUC). > > Philippe > > Reproducer: package P is S : constant String (1 .. 1_800_000_000) := (others => 'a'); end P; with P; wit h Text_Io; use Text_Io; procedure Pm is begin Put_Line (P.S (1..10) & P.S(100..110)); end; A solution is to link the user executable at an address 'high enough' above the valgrind address: gnatmake -g pm ... valgrind ./pm valgrind: mmap(0x10e000, 1800007680) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. rm ./pm gnatmake -g pm -largs -Wl,-Ttext-segment=0x68000000 ... valgrind ./pm ... ==19326== Warning: set address range perms: large range [0x68006000, 0xd34a5000) (defined) aaaaaaaaaaaaaaaaaaaaa ==19326== ==19326== HEAP SUMMARY: .... (valgrind itself is loaded at 0x58000000). We might maybe improve the valgrind mmap error detection and error message to indicate this solution. Philippe |
|
From: Philippe W. <phi...@sk...> - 2019-08-19 21:31:38
|
On Mon, 2019-08-19 at 14:25 -0700, John Reiser wrote: > > Strangely I now can't reproduce the problem. I get: > > > > ==5832== Memcheck, a memory error detector > > ==5832== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > > ==5832== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info > > Some of your earlier reports related to this issue were in 2017 and 2018. > valgrind often releases a new version approximately yearly. > > > ==5832== Command: /u/wh/rel/ifaplrel/pw_fwp_engine.eab > > ==5832== > > ==5832== Warning: set address range perms: large range [0xaef000, 0x13ef3000) (defined) > > ==5832== > > ==5832== Process terminating with default action of signal 6 (SIGABRT) > > ==5832== at 0x16592207: raise (in /usr/lib64/libc-2.17.so <http://libc-2.17.so/>;) > > ==5832== by 0x16593A37: abort (in /usr/lib64/libc-2.17.so <http://libc-2.17.so/>;) > <<snip>> > > ==5832== by 0x7FD209: ada__exceptions__raise_with_location_and_msg (a-except.adb:1168) > > ==5832== by 0x7FD1C4: __gnat_raise_storage_error_msg (a-except.adb:1145) > <<snip>> > > Before I would receive a message stating: > > > > valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid > > argument). > > valgrind: this can be caused by executables with very large text, data or bss > > segments. > > Should I use the other mailing list? > > You should: > 1) File a bug report, and post here a link to the bug report. > 2) Attach to the bug report the source code for a reproducible test case. > Please use C language. If Ada, then be EXPLICIT about your build tools and recipe. > > IF YOU DO NOT DO THOSE TWO THINGS, THEN YOUR COMPLAINT LIKELY WILL BE FORGOTTEN AND/OR IGNORED. Effectively. Note that it just took me now about 1 minute and 5 lines of code to reproduce it in Ada (but I guess it can be done in whatever language: it is enough to just produce a very large BSS). So, valgrind error message is correctly pointing at the problem of very large bss (as was already determined in 2017 IIUC). Philippe |
|
From: John R. <jr...@bi...> - 2019-08-19 21:25:30
|
> Strangely I now can't reproduce the problem. I get: > > ==5832== Memcheck, a memory error detector > ==5832== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==5832== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info Some of your earlier reports related to this issue were in 2017 and 2018. valgrind often releases a new version approximately yearly. > ==5832== Command: /u/wh/rel/ifaplrel/pw_fwp_engine.eab > ==5832== > ==5832== Warning: set address range perms: large range [0xaef000, 0x13ef3000) (defined) > ==5832== > ==5832== Process terminating with default action of signal 6 (SIGABRT) > ==5832== at 0x16592207: raise (in /usr/lib64/libc-2.17.so <http://libc-2.17.so/>) > ==5832== by 0x16593A37: abort (in /usr/lib64/libc-2.17.so <http://libc-2.17.so/>) <<snip>> > ==5832== by 0x7FD209: ada__exceptions__raise_with_location_and_msg (a-except.adb:1168) > ==5832== by 0x7FD1C4: __gnat_raise_storage_error_msg (a-except.adb:1145) <<snip>> > Before I would receive a message stating: > > valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid > argument). > valgrind: this can be caused by executables with very large text, data or bss > segments. > Should I use the other mailing list? You should: 1) File a bug report, and post here a link to the bug report. 2) Attach to the bug report the source code for a reproducible test case. Please use C language. If Ada, then be EXPLICIT about your build tools and recipe. IF YOU DO NOT DO THOSE TWO THINGS, THEN YOUR COMPLAINT LIKELY WILL BE FORGOTTEN AND/OR IGNORED. |
|
From: Petar J. <pe...@so...> - 2019-08-19 17:38:33
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4571112b501786da40d2a02f6a62e8fd75d10899 commit 4571112b501786da40d2a02f6a62e8fd75d10899 Author: Petar Jovanovic <mip...@gm...> Date: Mon Aug 19 17:37:17 2019 +0000 mips32: hook up getitimer syscall Hook up getitimer syscall for mips32. This fixes getitimer01 and several other tests in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index 0f29aca..6da479b 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -870,7 +870,7 @@ static SyscallTableEntry syscall_main_table[] = { LINXY (__NR_socketcall, sys_socketcall), // 102 LINXY (__NR_syslog, sys_syslog), // 103 GENXY (__NR_setitimer, sys_setitimer), // 104 - //.. GENXY(__NR_getitimer, sys_getitimer), // 105 + GENXY (__NR_getitimer, sys_getitimer), // 105 GENXY (__NR_stat, sys_newstat), // 106 GENXY (__NR_lstat, sys_newlstat), // 107 GENXY (__NR_fstat, sys_newfstat), // 108 |
|
From: Petar J. <pe...@so...> - 2019-08-19 17:38:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=7cac90f6ba880212a6d97983bb61c57969165559 commit 7cac90f6ba880212a6d97983bb61c57969165559 Author: Petar Jovanovic <mip...@gm...> Date: Mon Aug 19 17:23:58 2019 +0000 mips32: hook up sethostname syscall Hook up sethostname syscall for mips32. This fixes sethostname01 and several other tests in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index f32e02d..0f29aca 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -839,7 +839,7 @@ static SyscallTableEntry syscall_main_table[] = { GENX_ (__NR_setregid, sys_setregid), // 71 // PLAX_(__NR_sigsuspend, sys_sigsuspend), // 72 LINXY (__NR_sigpending, sys_sigpending), // 73 - //.. // (__NR_sethostname, sys_sethostname), // 74 + GENX_ (__NR_sethostname, sys_sethostname), // 74 GENX_ (__NR_setrlimit, sys_setrlimit), // 75 GENXY (__NR_getrlimit, sys_getrlimit), // 76 GENXY (__NR_getrusage, sys_getrusage), // 77 |
|
From: João M. S. S. <joa...@gm...> - 2019-08-19 16:22:24
|
Thanks, I didn't know it was adequate to submit a bug report in this case. Strangely I now can't reproduce the problem. I get: ==5832== Memcheck, a memory error detector ==5832== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5832== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info ==5832== Command: /u/wh/rel/ifaplrel/pw_fwp_engine.eab ==5832== ==5832== Warning: set address range perms: large range [0xaef000, 0x13ef3000) (defined) ==5832== ==5832== Process terminating with default action of signal 6 (SIGABRT) ==5832== at 0x16592207: raise (in /usr/lib64/libc-2.17.so) ==5832== by 0x16593A37: abort (in /usr/lib64/libc-2.17.so) ==5832== by 0x16354E90: uw_init_context_1 (unwind-dw2.c:1580) ==5832== by 0x16355A17: _Unwind_Backtrace (unwind.inc:283) ==5832== by 0x816280: __gnat_backtrace (in /u/wh/rel/ifaplrel/pw_fwp_engine.eab) ==5832== by 0x80BE7C: system__traceback__call_chain__2 (s-traceb.adb:93) ==5832== by 0x80BEA4: system__traceback__call_chain (s-traceb.adb:109) ==5832== by 0x7FCCE9: ada__exceptions__call_chain (a-excach.adb:65) ==5832== by 0x7FCE3C: ada__exceptions__complete_occurrence (a-except.adb:928) ==5832== by 0x7FCE6C: ada__exceptions__complete_and_propagate_occurrence (a-except.adb:942) ==5832== by 0x7FD209: ada__exceptions__raise_with_location_and_msg (a-except.adb:1168) ==5832== by 0x7FD1C4: __gnat_raise_storage_error_msg (a-except.adb:1145) ==5832== ==5832== HEAP SUMMARY: ==5832== in use at exit: 84,788 bytes in 16 blocks ==5832== total heap usage: 27 allocs, 11 frees, 161,226 bytes allocated ==5832== ==5832== LEAK SUMMARY: ==5832== definitely lost: 0 bytes in 0 blocks ==5832== indirectly lost: 0 bytes in 0 blocks ==5832== possibly lost: 704 bytes in 1 blocks ==5832== still reachable: 84,084 bytes in 15 blocks ==5832== suppressed: 0 bytes in 0 blocks ==5832== Rerun with --leak-check=full to see details of leaked memory ==5832== ==5832== For lists of detected and suppressed errors, rerun with: -s ==5832== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) FWP/start_pw.ebb: line 30: 5832 Aborted (core dumped) valgrind /u/wh/rel/ifaplrel/pw_fwp_engine.eab Before I would receive a message stating: valgrind: mmap(0xa64000, 1793339392) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. either with Red Hat's yum installed Valgrind or compiled from git. Should I use the other mailing list? João M. S. Silva On Sat, Aug 17, 2019 at 12:18 AM John Reiser <jr...@bi...> wrote: > >> Is Valgrind now able to load programs with really large BSS and data > segments (4 GB)? > > >> I have asked this before: > https://www.mail-archive.com/search?l=val...@li...&q=subject:%22Re%5C%3A+%5C%5BValgrind%5C-users%5C%5D+failed+in+UME+with+error+22%22&o=newest > > Is this possible now, or can this be an improvement? > > > > Can anyone clarify? > > > It is likely that there will be no progress until: > > 1) Create a bug report. Start at http://valgrind.org/ and follow the > "Bug Reports" > link in the left column. Publish here (on the mailing list) a link to the > bug report. > > 2) Attach to the bug report the source code of a short stand-alone program > in C language > which triggers the complaint. Give the build recipe to create the > executable file, > and the invocation command line for valgrind. > > If there is no bug report, then the issue likely will be forgotten. > The mailing list is not a substitute for the bug report. > If there is no reproducible test case, then likely no one will work on it. > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Petar J. <pe...@so...> - 2019-08-19 14:39:19
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4fbfffd8c8ece988b24cd2d349421f49d445c60b commit 4fbfffd8c8ece988b24cd2d349421f49d445c60b Author: Petar Jovanovic <mip...@gm...> Date: Mon Aug 19 14:38:34 2019 +0000 update NEWS with fix for #400593 The KDE issue #400593 has been fixed in commit c6a6cf929f3e2a9bf5d7f09f334ed4d67f2d6e18 Use statx rather than other stat system calls Diff: --- NEWS | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS b/NEWS index 6d55d76..e4fdd94 100644 --- a/NEWS +++ b/NEWS @@ -47,6 +47,7 @@ To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed below. +400593 In Coregrind, use statx for some internal syscalls if [f]stat[64] fail 406561 mcinfcallWSRU gdbserver_test fails on ppc64 406824 Unsupported baseline 407218 Add support for the copy_file_range syscall |
|
From: Julian S. <se...@so...> - 2019-08-19 14:05:38
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=e7dde4bc20bf57b4c1e25801f8462d1519c4fa41 commit e7dde4bc20bf57b4c1e25801f8462d1519c4fa41 Author: Julian Seward <js...@ac...> Date: Mon Aug 19 16:03:01 2019 +0200 Bug 400538 - vex amd64->IR: unhandled instruction bytes: 0x48 0xCF (IRETQ). Patch from Daniel Lehman <dle...@gm...>. Diff: --- VEX/priv/guest_amd64_toIR.c | 81 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c index 96dee38..4bba03c 100644 --- a/VEX/priv/guest_amd64_toIR.c +++ b/VEX/priv/guest_amd64_toIR.c @@ -21050,6 +21050,87 @@ Long dis_ESC_NONE ( } goto decode_failure; + case 0xCF: /* IRET */ + /* Note, this is an extremely kludgey and limited implementation of iret + based on the extremely kludgey and limited implementation of iret for x86 + popq %RIP; popl %CS; popq %RFLAGS; popq %RSP; popl %SS + %CS and %SS are ignored */ + if (sz != 8 || have66orF2orF3(pfx)) goto decode_failure; + + t1 = newTemp(Ity_I64); /* RSP */ + t2 = newTemp(Ity_I64); /* new RIP */ + /* t3 = newTemp(Ity_I32); new CS */ + t4 = newTemp(Ity_I64); /* new RFLAGS */ + t5 = newTemp(Ity_I64); /* new RSP */ + /* t6 = newTemp(Ity_I32); new SS */ + + assign(t1, getIReg64(R_RSP)); + assign(t2, loadLE(Ity_I64, binop(Iop_Add64,mkexpr(t1),mkU64(0)))); + /* assign(t3, loadLE(Ity_I32, binop(Iop_Add64,mkexpr(t1),mkU64(8)))); */ + assign(t4, loadLE(Ity_I64, binop(Iop_Add64,mkexpr(t1),mkU64(16)))); + assign(t5, loadLE(Ity_I64, binop(Iop_Add64,mkexpr(t1),mkU64(24)))); + /* assign(t6, loadLE(Ity_I32, binop(Iop_Add64,mkexpr(t1),mkU64(32)))); */ + + /* set %RFLAGS */ + stmt( IRStmt_Put( OFFB_CC_OP, mkU64(AMD64G_CC_OP_COPY) )); + stmt( IRStmt_Put( OFFB_CC_NDEP, mkU64(0) )); + stmt( IRStmt_Put( OFFB_CC_DEP2, mkU64(0) )); + stmt( IRStmt_Put( OFFB_CC_DEP1, + binop(Iop_And64, + mkexpr(t4), + mkU64( AMD64G_CC_MASK_C | AMD64G_CC_MASK_P + | AMD64G_CC_MASK_A | AMD64G_CC_MASK_Z + | AMD64G_CC_MASK_S| AMD64G_CC_MASK_O ) + ) + ) + ); + + /* Also need to set the D flag, which is held in bit 10 of t4. + If zero, put 1 in OFFB_DFLAG, else -1 in OFFB_DFLAG. */ + stmt( IRStmt_Put( + OFFB_DFLAG, + IRExpr_ITE( + unop(Iop_64to1, + binop(Iop_And64, + binop(Iop_Shr64, mkexpr(t4), mkU8(10)), + mkU64(1))), + mkU64(0xFFFFFFFFFFFFFFFFULL), + mkU64(1))) + ); + + /* And set the ID flag */ + stmt( IRStmt_Put( + OFFB_IDFLAG, + IRExpr_ITE( + unop(Iop_64to1, + binop(Iop_And64, + binop(Iop_Shr64, mkexpr(t4), mkU8(21)), + mkU64(1))), + mkU64(1), + mkU64(0))) + ); + + /* And set the AC flag too */ + stmt( IRStmt_Put( + OFFB_ACFLAG, + IRExpr_ITE( + unop(Iop_64to1, + binop(Iop_And64, + binop(Iop_Shr64, mkexpr(t4), mkU8(18)), + mkU64(1))), + mkU64(1), + mkU64(0))) + ); + + + /* set new stack */ + putIReg64(R_RSP, mkexpr(t5)); + + /* goto new RIP value */ + jmp_treg(dres, Ijk_Ret, t2); + DIP("iret (very kludgey)\n"); + return delta; + case 0xD0: { /* Grp2 1,Eb */ Bool decode_OK = True; if (haveF2orF3(pfx)) goto decode_failure; |