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
(14) |
2
(16) |
3
(13) |
4
(3) |
|
5
(18) |
6
(1) |
7
(6) |
8
(2) |
9
(16) |
10
(19) |
11
(14) |
|
12
(1) |
13
(6) |
14
(20) |
15
(26) |
16
(18) |
17
(15) |
18
(16) |
|
19
(7) |
20
(8) |
21
(19) |
22
(19) |
23
(21) |
24
(15) |
25
(15) |
|
26
(11) |
27
(17) |
28
(21) |
29
(14) |
|
|
|
|
From: Philippe W. <phi...@sk...> - 2012-02-19 20:08:51
|
On Sun, 2012-02-19 at 19:30 +0100, Philippe Waroquiers wrote:
> Outer helgrind + inner none goes further, but then the outer generates a SEGV
> when computing a backtrace when the thread 1 is cloning a thread 2.
Adding to the inner none tool --vex-iropt-precise-memory-exns=yes
seems to solve the problem (at least, the 4 threads are starting up).
>
> Any idea if the patch below is the way to go ?
> Or if there is something which I have not understood/did wrong ?
If positive feedback about the below patch, I will clean it up
and modify the README_DEVELOPPERS to speak about
-vex-iropt-precise-memory-exns=yes
Philippe
>
> Philippe
>
> ndex: coregrind/m_redir.c
> ===================================================================
> --- coregrind/m_redir.c (revision 12391)
> +++ coregrind/m_redir.c (working copy)
> @@ -49,6 +49,7 @@
> #include "pub_core_xarray.h"
> #include "pub_core_clientstate.h" // VG_(client___libc_freeres_wrapper)
> #include "pub_core_demangle.h" // VG_(maybe_Z_demangle)
> +#include "pub_core_libcproc.h" // VG_(libdir)
>
> #include "config.h" /* GLIBC_2_* */
>
> @@ -389,6 +390,7 @@
> Bool isText;
> const UChar* newdi_soname;
>
> +
> # if defined(VG_PLAT_USES_PPCTOC)
> check_ppcTOCs = True;
> # endif
> @@ -397,6 +399,23 @@
> newdi_soname = VG_(DebugInfo_get_soname)(newdi);
> vg_assert(newdi_soname != NULL);
>
> +#ifdef ENABLE_INNER
> + {
> + const UChar* newdi_filename;
> + VG_(message)(Vg_DebugMsg, "VALGRIND_LIB %s\n", VG_(libdir));
> + newdi_filename = VG_(DebugInfo_get_filename)(newdi);
> + VG_(message)(Vg_DebugMsg, "checking ignoring redir in %s %s\n", newdi_soname, newdi_filename);
> + /* avoid reading the redirections which are for the outer. */
> + if (VG_(strstr)(newdi_filename, "/vgpreload")) {
> + VG_(message)(Vg_DebugMsg, "contains /vgpreload\n");
> + if( !VG_(strstr)(newdi_filename, (Char*) VG_(libdir))) {
> + VG_(message)(Vg_DebugMsg, "not containing inner VG_(libdir) => ignoring redir in %s\n", newdi_filename);
> + return;
> + }
> + }
> + }
> +#endif
> +
> /* stay sane: we don't already have this. */
> for (ts = topSpecs; ts; ts = ts->next)
> vg_assert(ts->seginfo != newdi);
|
|
From: Florian K. <br...@ac...> - 2012-02-19 18:36:21
|
On 02/19/2012 12:44 PM, Julian Seward wrote: > >>> One way to mostly get what you want is to suppress your optimisation >>> just for the first PUT(IP) = ... in the block (iow, make sure the >>> first is always an 8 byte PUT). After that you should be safe. I don't >>> know if you can do this without changing the the generic interface >>> used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. >> >> Exactly, that is what I had coded up. > > So .. did you arrive at something which works reliably? (is unclear > from your mail) > Yes. Making the first PUT(IP) in an IRSB an 8-byte PUT solved the problem. I did not run a full regtest after that but would not expect any surprises. >> I had something similar in mind, namely to track the contents of certain >> guest state entries: IA and condition code thunk. The rationale is that >> newer s390's have an insn to add an 8-bit immediate to a storage >> location. So an update of the guest_IA is a single insn in most cases. >> No register being used. >> >> Binding the guest_IA to a temp creates a loooong lifetime which the >> register allocator will not like... > > Well, it all depends, right? That's the compiler-writing game. Yes. But: > The add-8-bit-immediate is going to give one load-op-store triple > per update, No. I was perhaps unclear. The instruction I have in mind to update the guest state operates on memory directly. There is not going to be a load-op-store triple. Now, to do that I need to add a new insn to the insn selector, namely: add this value to the guest state at offset so-and-so. That should be a clear win at least for IA because that value is almost never read. For the condition code thunk the jury is out. If the PUT doesn't create a temporary the next GET will access memory instead of the temporary. Will have to see how often that happens. Florian |
|
From: Philippe W. <phi...@sk...> - 2012-02-19 18:30:03
|
For working on multi-threaded valgrind, I am trying helgrind or drd
on a none tool. This does not work.
>From what I have experimented, any outer tool that redirects
malloc/free/... will not work with an inner tool that does not
redirect malloc/free/...
Typically, an outer memcheck/helgrind/drd/... cannot run an
inner none/callgrind/cachegrind
(confirmed by doing all combinations. They all fail for similar
reasons. The below discusses helgrind+none more in details).
The symptoms (for an outer helgrind and inner none): a thread cannot be
created (see below). Investigating further, this is caused by malloc/...
not working. When run with outer helgrind + inner none, the malloc
calls returns 0x0. The inner also complaints it can't handle helgrind
client request (see below).
After investigation, I have concluded that the problem is that the inner
tool (none in this case) is interpreting the redirection special symbols
found in the vgpreload of the outer tool.
So, the none tool is "installing" redirection for e.g. malloc to
redirect to a function it does not have.
Extract of the trace of the problem (see func=0x0)
>--14266:2:transtab discard_translations(0x4e26d93, 1) req by redir_new_DebugInfo(to_addr)
>--14266:2:transtab FAST, ec = 77
>==14266== Adding active redirection:
>--14266-- new: 0x052c9750 (memcpy ) R-> (0000.0) 0x04e26d93 memcpy
>--14266-- REDIR: 0x52c08c0 (malloc) redirected to 0x4e25c68 (malloc)
>--14266-- VG_USERREQ__CLIENT_CALL1: func=0x0
loops/sleep_ms/burn/threads_spec: 100000 0 10000 B-B-B-B-
>--14266-- REDIR: 0x5034c30 (pthread_create@@GLIBC_2.2.5) redirected to 0x4e2ae52 (pthread_create@*)
>==14266== Warning:
>==14266== unhandled client request: 0x48470127 (HG+0x127). Perhaps
>==14266== VG_(needs).client_requests should be set?
>--14266-- REDIR: 0x52bfe50 (calloc) redirected to 0x4e24f2b (calloc)
>--14266-- VG_USERREQ__CLIENT_CALL2: func=0x0
>--14266-- REDIR: 0x5038660 (pthread_rwlock_rdlock) redirected to 0x4e280df (pthread_rwlock_rdlock)
>--14266-- REDIR: 0x52c9750 (memcpy) redirected to 0x4e26d93 (memcpy)
>--14266-- REDIR: 0x5038c70 (pthread_rwlock_unlock) redirected to 0x4e27c04 (pthread_rwlock_unlock)
>--14266-- VG_USERREQ__CLIENT_CALL1: func=0x0
Unexpected error.
--14266:1:gdbsrv signal 6 tid 1
--14266:1:gdbsrv not connected => pass
>--14266:1:gdbsrv signal 6 tid 1
>--14266:1:gdbsrv not connected => pass
>==14266==
>==14266== Process terminating with default action of signal 6 (SIGABRT)
>--14266:1:mallocfr newSuperblock at 0x3F4254000 (pszB 1048544) owner VALGRIND/exectxt
>==14266== at 0x527C165: raise (raise.c:64)
>==14266== by 0x527EF6F: abort (abort.c:92)
>==14266== by 0x52752B0: __assert_fail (assert.c:81)
>==14266== by 0x503537C: pthread_create@@GLIBC_2.2.5 (allocatestack.c:573)
>==14266== by 0x4E2AD46: pthread_create_WRK (hg_intercepts.c:255)
>==14266== by 0x4E2AE5A: pthread_create@* (hg_intercepts.c:286)
>==14266== by 0x400F3A: main (parallel_sleepers.c:161)
>--14266:1:syswrap- thread_wrapper(tid=1): exit
>--14266:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
>--14266:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
I have somewhat bypassed the problem with the patch below,
which avoids the inner to execute the redirection of a vgpreload
of the outer.
It looks like an outer helgrind+inner cachegrind goes much
better (still running).
Outer helgrind + inner none goes further, but then the outer generates a SEGV
when computing a backtrace when the thread 1 is cloning a thread 2.
Any idea if the patch below is the way to go ?
Or if there is something which I have not understood/did wrong ?
Philippe
ndex: coregrind/m_redir.c
===================================================================
--- coregrind/m_redir.c (revision 12391)
+++ coregrind/m_redir.c (working copy)
@@ -49,6 +49,7 @@
#include "pub_core_xarray.h"
#include "pub_core_clientstate.h" // VG_(client___libc_freeres_wrapper)
#include "pub_core_demangle.h" // VG_(maybe_Z_demangle)
+#include "pub_core_libcproc.h" // VG_(libdir)
#include "config.h" /* GLIBC_2_* */
@@ -389,6 +390,7 @@
Bool isText;
const UChar* newdi_soname;
+
# if defined(VG_PLAT_USES_PPCTOC)
check_ppcTOCs = True;
# endif
@@ -397,6 +399,23 @@
newdi_soname = VG_(DebugInfo_get_soname)(newdi);
vg_assert(newdi_soname != NULL);
+#ifdef ENABLE_INNER
+ {
+ const UChar* newdi_filename;
+ VG_(message)(Vg_DebugMsg, "VALGRIND_LIB %s\n", VG_(libdir));
+ newdi_filename = VG_(DebugInfo_get_filename)(newdi);
+ VG_(message)(Vg_DebugMsg, "checking ignoring redir in %s %s\n", newdi_soname, newdi_filename);
+ /* avoid reading the redirections which are for the outer. */
+ if (VG_(strstr)(newdi_filename, "/vgpreload")) {
+ VG_(message)(Vg_DebugMsg, "contains /vgpreload\n");
+ if( !VG_(strstr)(newdi_filename, (Char*) VG_(libdir))) {
+ VG_(message)(Vg_DebugMsg, "not containing inner VG_(libdir) => ignoring redir in %s\n", newdi_filename);
+ return;
+ }
+ }
+ }
+#endif
+
/* stay sane: we don't already have this. */
for (ts = topSpecs; ts; ts = ts->next)
vg_assert(ts->seginfo != newdi);
|
|
From: Julian S. <js...@ac...> - 2012-02-19 17:44:51
|
> > One way to mostly get what you want is to suppress your optimisation > > just for the first PUT(IP) = ... in the block (iow, make sure the > > first is always an 8 byte PUT). After that you should be safe. I don't > > know if you can do this without changing the the generic interface > > used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. > > Exactly, that is what I had coded up. So .. did you arrive at something which works reliably? (is unclear from your mail) > > Another way to get what you want is to put the cleverness in the back > > end instead. In the insn selector, keep track (perhaps in the ISelEnv) > > of which virtual regs have known constants. Then, when you see > > "PUT(...) = 64-bit constant", see if you can do it with > > > > rTemp = (selected vreg) + small constant > > *(rBaseblock + offs_IP) = rTemp > > I had something similar in mind, namely to track the contents of certain > guest state entries: IA and condition code thunk. The rationale is that > newer s390's have an insn to add an 8-bit immediate to a storage > location. So an update of the guest_IA is a single insn in most cases. > No register being used. > > Binding the guest_IA to a temp creates a loooong lifetime which the > register allocator will not like... Well, it all depends, right? That's the compiler-writing game. The add-8-bit-immediate is going to give one load-op-store triple per update, whereas having a reg with a long lifetime is gives only one op-store pair per update, plus some unknowable spill-restore cost if there's a lot of pressure on registers. Who knows which is better. J |
|
From: Florian K. <br...@ac...> - 2012-02-19 17:11:03
|
On 02/19/2012 06:10 AM, Julian Seward wrote: > > The translation will have > PUT(offs-PC) = some-address-in-vgpreload_memcheck-amd64-linux.so:malloc > for its PC update IR fragments. But remember, the program actually > called libc.so:malloc, and so the value stored in > guest_state->PC at that point (when the translation is made) is > the entry point for libc.so:malloc. > > For this all to make sense, the translation table (managed by > m_transtab) contains a binding > (&libc.so:malloc -> this translation), so that subsequent calls > by the program to libc.so:malloc lead back to this translation. > > This, I suspect, has much to do with what you observe. Fun, > isn't it :-) > Yep, this explains pretty much what I see. Thanks for taking the time. > One way to mostly get what you want is to suppress your optimisation > just for the first PUT(IP) = ... in the block (iow, make sure the > first is always an 8 byte PUT). After that you should be safe. I don't > know if you can do this without changing the the generic interface > used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. > Exactly, that is what I had coded up. > Another way to get what you want is to put the cleverness in the back > end instead. In the insn selector, keep track (perhaps in the ISelEnv) > of which virtual regs have known constants. Then, when you see > "PUT(...) = 64-bit constant", see if you can do it with > > rTemp = (selected vreg) + small constant > *(rBaseblock + offs_IP) = rTemp I had something similar in mind, namely to track the contents of certain guest state entries: IA and condition code thunk. The rationale is that newer s390's have an insn to add an 8-bit immediate to a storage location. So an update of the guest_IA is a single insn in most cases. No register being used. Binding the guest_IA to a temp creates a loooong lifetime which the register allocator will not like... Florian |
|
From: Julian S. <js...@ac...> - 2012-02-19 11:11:17
|
> > The places where the PC appears to be wrong: are these exactly the > > first basic blocks of redirected functions (in the sense of the > > functions defined in eg memcheck/mc_replace_strmem.c) ? > > I just reran with --trace-redir=yes and in all cases where the PC > appeared to be wrong it was a redir translation. From that, I'd guess that the reason is that there's a difference between the PC values baked into the PUTs in the IR, and the value of PC in the guest state, for these specific blocks. eg. suppose the program calls libc.so:malloc for the first time. m_redir knows that a replacement exists (vgpreload_memcheck-amd64-linux.so:malloc) and so it directs VEX to translate the entry point of the replacement instead. The translation will have PUT(offs-PC) = some-address-in-vgpreload_memcheck-amd64-linux.so:malloc for its PC update IR fragments. But remember, the program actually called libc.so:malloc, and so the value stored in guest_state->PC at that point (when the translation is made) is the entry point for libc.so:malloc. For this all to make sense, the translation table (managed by m_transtab) contains a binding (&libc.so:malloc -> this translation), so that subsequent calls by the program to libc.so:malloc lead back to this translation. This, I suspect, has much to do with what you observe. Fun, isn't it :-) Some random comments: ----------------- One way to mostly get what you want is to suppress your optimisation just for the first PUT(IP) = ... in the block (iow, make sure the first is always an 8 byte PUT). After that you should be safe. I don't know if you can do this without changing the the generic interface used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. ----------------- Another way to get what you want is to put the cleverness in the back end instead. In the insn selector, keep track (perhaps in the ISelEnv) of which virtual regs have known constants. Then, when you see "PUT(...) = 64-bit constant", see if you can do it with rTemp = (selected vreg) + small constant *(rBaseblock + offs_IP) = rTemp ----------------- Yet another way to do it is to transform the IR in iropt.c, at some suitable place (not sure where), and essentially do the same as above at the IR level. This would also help other targets where constant generation is expensive, particularly ppc64 and to a lesser extent arm. ----------------- Of course the whole concept of updating the guest IP as we run is a ridiculous inefficiency anyway. At least in principle we should be able to use the IRMarks to construct a mapping table that maps host PCs to guest PCs for any host PC. I would long ago have done this but for the (major) complication of how to establish the host PC (and hence the guest PC) when we are in some helper function called from generated code and want to get a (guest) stack trace. Then we have to have a way to get hold of the return value of the helper function (or, more generally of the outermost helper function if we're in some stack of helper calls) in a way which always works and works across all the supported architectures. So far I haven't figured out how. (Suggestions welcomed). J |
|
From: Florian K. <br...@ac...> - 2012-02-19 01:03:42
|
On 02/18/2012 05:23 PM, Julian Seward wrote:
>
> If I had to guess, I'd say you've fallen into the swamp of complexity
> that is the difference between "redir" and "no-redir" translations.
> I tried but failed to find in the sources, a comment explaining about
> this, so before I write a long explaination, can I ask:
>
> The places where the PC appears to be wrong: are these exactly the
> first basic blocks of redirected functions (in the sense of the
> functions defined in eg memcheck/mc_replace_strmem.c) ?
>
I just reran with --trace-redir=yes and in all cases where the PC
appeared to be wrong it was a redir translation.
For the failing regtest here is the redirect:
--24258-- REDIR: 0x49b60ab398 (index) redirected to 0x400933c (index)
GUEST_IA 49B60AB398 CURR_IA 400933C PUT_IP == 0
GUEST_IA 49B60AB398 PREV_IA 400933C CURR_IA 4009342
GUEST_IA 49B60AB398 PREV_IA 4009342 CURR_IA 4009348
.....
Shouldn't the PC in the guest state be updated here as well?
Florian
>
> On Saturday, February 18, 2012, Florian Krohm wrote:
>> Hi,
>>
>> I was attempting an optimization on s390x where updating the instruction
>> address in the guest state is an expensive operation. Piecing together
>> the 64-bit immediate value takes 4 (or 2) insns depending on model. So
>> I thought I could do the following (and save 2% - 5% of insns):
>>
>> if (put_IP) {
>> // If upper half is the same just update the lower half
>> if ((previous_IA >> 32) == (current_IA >> 32))
>> update lower 4 byte of instruction address in guest state
>> else
>> update full 8 byte of instruction address in guest state
>> }
>> previous_IA = current_IA;
>>
>> But I was proven wrong. memcheck/tests/strchr was failing by telling me:
>>
>> ==23763== Conditional jump or move depends on uninitialised value(s)
>> ==23763== at 0x4904009366: ??? <------<<
>> ==23763== by 0x8000067B: main (strchr.c:15)
>> ==23763==
>>
>> instead of
>>
>> ==22402== Conditional jump or move depends on uninitialised value(s)
>> ==22402== at 0x4009366: index (mc_replace_strmem.c:210)
>> ==22402== by 0x8000067B: main (strchr.c:15)
>> ==22402==
>>
>> I believe that the reason for this failure is that the instruction
>> address in the guest state is not set as expected when some brandnew
>> jitted code is executed for the first time. It is expected in
>> guest_generic_bb_to_IR:
>>
>> /* for the first insn, the dispatch loop will have set
>> %IP, but for all the others we have to do it ourselves. */
>> need_to_put_IP = toBool(n_instrs > 0);
>>
>> /* Finally, actually disassemble an instruction. */
>> dres = dis_instr_fn ( irsb,
>> need_to_put_IP,
>>
>> With some debug printf I see this happening:
>> (GUEST_IA is the contents of the instruction address in the guest state)
>>
>> In the disassembler when translating:
>>
>> GUEST_IA 49B60AB398 CURR_IA 400933C PUT_IP == 0
>> GUEST_IA 49B60AB398 PREV_IA 400933C CURR_IA 4009342
>> GUEST_IA 49B60AB398 PREV_IA 4009342 CURR_IA 4009348
>> GUEST_IA 49B60AB398 PREV_IA 4009348 CURR_IA 400934C
>> GUEST_IA 49B60AB398 PREV_IA 400934C CURR_IA 4009350
>> GUEST_IA 49B60AB398 PREV_IA 4009350 CURR_IA 400935E
>> GUEST_IA 49B60AB398 PREV_IA 400935E CURR_IA 4009364
>> GUEST_IA 49B60AB398 PREV_IA 4009364 CURR_IA 4009366
>> GUEST_IA 49B60AB398 PREV_IA 4009366 CURR_IA 400936A
>> GUEST_IA 49B60AB398 PREV_IA 400936A CURR_IA 4009370
>>
>> Right before entering VG_(run_innerloop) for execution it reports:
>>
>> CALLING run_innerloop: GUEST_IA is 49b60ab398
>>
>> I think that the GUEST_IA should have the value 400933C here.
>>
>> This is not due to a bug in the s390x dispatch loop. I see the same
>> thing (guest_EIP not having the expected value) also happening on x86.
>>
>> To summarize, I think there is a latent bug here which surfaced through
>> my optimization. Still, it should be corrected. Perhaps it is easiest to
>> just update the guest state all the time. That would (a) be correct and
>> (b) not hurt because IR optimization will remove the PUT anyhow if it is
>> not needed. I can cook up a patch if you think this is the right approach.
>>
>> Florian
|