|
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. |