|
From: Ivo R. <iv...@iv...> - 2015-03-30 09:14:13
|
Dear developers, Please could you shed some light on why setHelperAnns() in mc_translate.c annotates all memcheck's dirty helpers to indicate that IP and SP could be read? I guess the reason is that IP and SP are required for stack unwinding in case one of these dirty helpers detect a problem which needs to be reported. But if this is so, then why also FP is not present in annotations? FP is required on many arches for stack unwinding as well (even with help of debug info from DWARF). [Other tools do not use SP in annotating their dirty helpers, only memcheck does.] Kind regards, I. |
|
From: Julian S. <js...@ac...> - 2015-03-31 17:41:03
|
On 30/03/15 11:14, Ivo Raisr wrote: > Please could you shed some light on why setHelperAnns() > in mc_translate.c annotates all memcheck's dirty helpers > to indicate that IP and SP could be read? > > I guess the reason is that IP and SP are required for > stack unwinding in case one of these dirty helpers > detect a problem which needs to be reported. Yes, that is correct. > But if this is so, then why also FP is not present in annotations? Hmm. I don't know. My first impression is that this is a bug. How did you detect this? By code inspection, or did you see some unwind failures -- that is, direct evidence of unwind failures? J |
|
From: Ivo R. <iv...@iv...> - 2015-04-02 19:27:29
|
2015-03-31 19:40 GMT+02:00 Julian Seward <js...@ac...>: > On 30/03/15 11:14, Ivo Raisr wrote: > > Please could you shed some light on why setHelperAnns() > > in mc_translate.c annotates all memcheck's dirty helpers > > to indicate that IP and SP could be read? > > > > I guess the reason is that IP and SP are required for > > stack unwinding in case one of these dirty helpers > > detect a problem which needs to be reported. > > Yes, that is correct. > Thank you for confirmation. > > > But if this is so, then why also FP is not present in annotations? > > Hmm. I don't know. My first impression is that this is a bug. > > How did you detect this? By code inspection, or did you see some > unwind failures -- that is, direct evidence of unwind failures? > Code inspection. But further inspection showed that not all architectures have a register equivalent to FP. Primary suspects are ARM/ARM64, which do not even contain any sane value for offset_FP in the VEX guest layout. This means exp-sgcheck on such arches probably produces strange results. Back to memcheck annotations in setHelperAnns(). I tried to add another element of fxState for FP and - what surprise - no effect on x86+amd64/Linux. All tests passed, nothing failed. I have no access to arm to test there. But what I found is that annotations on dirty helpers injected *by tools* are not processed in any way. Only annotations on dirty helpers injected by guest->IR translation are processed by tool instrumentation functions. So I tried to remove annotations in setHelperAnns(). And - what surprise - no effect on x86+amd64/Linux. All tests passed, nothing failed. So this confirms my previous finding. Patch to add FP in setHelperAnns() is posted in bug report: https://bugs.kde.org/show_bug.cgi?id=345811 I. |
|
From: Philippe W. <phi...@sk...> - 2015-04-02 20:05:16
|
On Thu, 2015-04-02 at 21:27 +0200, Ivo Raisr wrote: > > Back to memcheck annotations in setHelperAnns(). I tried to add > another > > element of fxState for FP and - what surprise - no effect on x86 > +amd64/Linux. > All tests passed, nothing failed. I suspect that all this is working due to the default value: --vex-iropt-register-updates=unwindregs-at-mem-access Even if the dirty helper does not indicate that the FP must be up to date at dirty helper call, the above flag will ensure the FP has a correct value. I am wondering what is the behaviour of memcheck if we fix the dirty helper (i.e. indicate it reads FP) but use sp-at-mem-access for --vex-iropt-register-updates ? Are all tests still ok ? Philippe |
|
From: Ivo R. <iv...@iv...> - 2015-04-04 02:52:17
|
2015-04-02 22:05 GMT+02:00 Philippe Waroquiers < phi...@sk...>: > On Thu, 2015-04-02 at 21:27 +0200, Ivo Raisr wrote: > > > > Back to memcheck annotations in setHelperAnns(). I tried to add > > another element of fxState for FP and - what surprise - no effect on x86 > > +amd64/Linux. > > All tests passed, nothing failed. > > I suspect that all this is working due to the default value: > --vex-iropt-register-updates=unwindregs-at-mem-access > > Even if the dirty helper does not indicate > that the FP must be up to date at dirty helper call, > the above flag will ensure the FP has a correct value. > > I am wondering what is the behaviour of memcheck > if we fix the dirty helper (i.e. indicate it reads FP) > but use sp-at-mem-access for > --vex-iropt-register-updates? > Are all tests still ok? > You are right, the default --vex-iropt-register-updates=unwindregs-at-mem-access was in place. But "sp-at-mem-access" is not correct option for stack unwinding. I used "unwindregs-at-mem-access" instead to play with. So with --vex-iropt-register-updates=unwindregs-at-mem-access there is no difference whatsoever for the following cases: - setHelperAnns() with the fix (dirty helpers read FP) - setHelperAnns() without the fix (original state) - setHelperAnns() set no annotations at all [di->nFxState = 0] This supports my earlier statement that annotations on dirty helpers injected by *tools* are not processed, unlike annotations injected by guest->IR translation. https://bugs.kde.org/show_bug.cgi?id=345811 I. |