From: Frank N. <fn1...@in...> - 2007-03-29 16:34:10
|
> -----Ursprüngliche Nachricht----- > Von: jc...@st... > Gesendet: 29.03.07 14:25:55 > An: "Frank Naumann" <fn1...@in...> > CC: val...@li... > Betreff: Re: [Valgrind-users] SysCalls and data flow tracing (problem) > > Now when I try to search the point where 0x4146929 was stored, I cannot > > find it. > > The value "9" is not hardcoded in the printf command, so it should not be > > e.g. read > > directly out of the guest application binary. (at least I think so) > > So my conclusion is, there is something that writes to the memory at > > 0x4146929 and overrides > > the instrumentation. Since I really need to somehow trace this value back > > to originating > > variables (their addresses) (j,k). > > Any input is most welcome (thank you very much). > > > Maybe I do not understand you correctly, then please ignore this message. > But coregrind has constant propagation as optimization in the cheap > optimization steps, to be more precise in the first line of optimizations > directly after translating. When I look at the IR-code that you supply, I > believe that it is optimized code, so that constant propagation is already > done. > > To watch the non optimized code, you can just trace valgrind with > --trace-flags=10000000 (and set the --trace-notbelow flag correctly) to > see the IR directly after translation. > > > Regards, > > John > I do not ignore it, since it shows me, I did not explain my problem eactly. So I need to explain this a little deeper. What one can see there, is the result of heavily instrumented UCode. As far as I know (please correct me if I am wrong), the trace-flags and trace-notbelow forces a trace of the basic blocks before they are retranslated for execution. It represents basically how basic blocks look like in the instrumentation part (and how they are sequentially aligned for translation). Now the instrumentation part, is not of interest to me, because it does not show the true data flow in the guest application. Therefore I heavily instrumented the UCode to have a dirty helper assigned for each instrumentable statement (some, which are of little interest to me I simplified). So what one can see there, is how the guest application actually runs (not how it looks like in the instrumentation phase). It is however based on all the information that is provided during the instrumentation phase. Usually I would not even use something so heavily instrumented, but I could not help it. I need to find out, why certain values are not correctly propagated. To achieve this, I need real memory addresses (not something like e.g. t34=Get(0) t36=LOAD(t34-0x8)). So since I do not really need the trace (at least not like this), and since I want to know why certain values cannot be traced back by simply instrumenting the load/store commands (and using IRTemp and ArchReg shadowing), I made the guest application runtime code visual like this (which looks a little like the UCode trace pre-instrumented). I don't know why it doesn't work, but maybe an answer to these intermediate questions can help too: Is it possible, that the UCode provided for instrumentation is already pre-modified in a way, that some data flow cannot be tracked back? (I use the a standard run, no special flags set) I encounter these problems only with SysCalls. SysCalls seem to use a predefined memory area for interaction, in order to be able to do so, something has to transfer the information to this memory area. However, since I cannot trace back the data flow, I ask myself, if there is a method used, that cannot be instrumented in the instrumentation phase? To be blunt, I am pretty clueless at the moment. |