|
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. |
|
From: Frank N. <fn1...@in...> - 2007-03-30 03:43:54
|
> On Thu, 29 Mar 2007, Frank Naumann wrote: > > > 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'm not sure if I understand your problem. I think, that basically you want > to instrument every memory store, but some seem to be getting missed. Is > that right? > > One possible cause: Ist_Store statements are not the only IR statements > that can cause memory stores -- Ist_Dirty statements can as well. See > lackey/lk_main.c for example code that deals with this. (And the > pre_mem_write events can be used for tracking other stores that are not > visible from the IR, as I explained in a previous email.) > > Nick > Yes that is basically right (I want to instrument each load and store). I checked the Ist_Dirty statements (and implemented a Ist_Dirty memory tracking). Unfortunately this did not help, since there are no reading/writing/modifying Ist_Dirty statements used in this guest appliction (and I was already very optimistic, I was realy hoping Ist_Dirty is the cause). Well, so I still have the problem. All the post/pre_mem_writes use addresses above BEA00000 (not 401E00X). So there is no influence from this side. Is there anything else that can write to the memory? (maybe something I am not able to instrument?) Thank you for your patience |
|
From: Nicholas N. <nj...@cs...> - 2007-03-30 04:58:10
|
On Fri, 30 Mar 2007, Frank Naumann wrote: > Yes that is basically right (I want to instrument each load and store). I > checked the Ist_Dirty statements (and implemented a Ist_Dirty memory > tracking). Unfortunately this did not help, since there are no > reading/writing/modifying Ist_Dirty statements used in this guest > appliction (and I was already very optimistic, I was realy hoping > Ist_Dirty is the cause). Well, so I still have the problem. > All the post/pre_mem_writes use addresses above BEA00000 (not 401E00X). So > there is no influence from this side. > > Is there anything else that can write to the memory? (maybe something I am > not able to instrument?) The combination of Ist_Store, Ist_Dirty and pre_mem_write are supposed to cover all writes to memory. It's possible that some are slipping through. It's also possible that the Valgrind core or Valgrind tool has a bug and is writing into the client address space. I can't think of anything else. Nick |
|
From: Frank N. <fn1...@in...> - 2007-03-30 16:08:28
|
> On Fri, 30 Mar 2007, Frank Naumann wrote: > > > Yes that is basically right (I want to instrument each load and store). I > > checked the Ist_Dirty statements (and implemented a Ist_Dirty memory > > tracking). Unfortunately this did not help, since there are no > > reading/writing/modifying Ist_Dirty statements used in this guest > > appliction (and I was already very optimistic, I was realy hoping > > Ist_Dirty is the cause). Well, so I still have the problem. > > All the post/pre_mem_writes use addresses above BEA00000 (not 401E00X). So > > there is no influence from this side. > > > > Is there anything else that can write to the memory? (maybe something I am > > not able to instrument?) > > The combination of Ist_Store, Ist_Dirty and pre_mem_write are supposed to > cover all writes to memory. It's possible that some are slipping through. > It's also possible that the Valgrind core or Valgrind tool has a bug and is > writing into the client address space. I can't think of anything else. > > Nick > Thank you very much (your support is always very fast). Since you said, there is no other way to write to memory, that made my mind free for thinking about other possible causes. And then I found out something interesting: If there is a format string in the high level C-code printf (e.g. "%d"), the substitution for this format string will always read at a certain memory address. E.g. if the character '9' is to be loaded for pre_mem_read it will always load from address 0x4146929, if the character '0' is to be loaded it will always load from 0x4146920. And if the character '1' is to be loaded the loading address is 0x4146921. There seems to be something like a predefined character map, that the guest application is using to prepare pre_mem_read strings for the SysCalls triggered by the C high level instruction printf. I think I can handle this now. Thanks again. |
|
From: Nicholas N. <nj...@cs...> - 2007-03-30 00:07:21
|
On Thu, 29 Mar 2007, Frank Naumann wrote: > 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'm not sure if I understand your problem. I think, that basically you want to instrument every memory store, but some seem to be getting missed. Is that right? One possible cause: Ist_Store statements are not the only IR statements that can cause memory stores -- Ist_Dirty statements can as well. See lackey/lk_main.c for example code that deals with this. (And the pre_mem_write events can be used for tracking other stores that are not visible from the IR, as I explained in a previous email.) Nick |