|
From: Jeremy F. <je...@go...> - 2003-12-19 00:26:07
|
On Thu, 2003-12-18 at 12:12, Josef Weidendorfer wrote: > On Thursday 18 December 2003 19:17, Josef Weidendorfer wrote: > > Where should I allocate space for this flag? > > Or better: How to get rid of the permission check, i.e. the "%fs:" segment? > > Followup: > Of course, with --pointercheck=no, I can avoid the %fs prefix. But in this > case, this should be avoided even with --pointercheck=yes, as this is a > STORE instruction generated by the tool. > As LOAD/STORE always does a bound check, there are 3 possibilities: > * I add an extended UCode for this, > * We add LOAD/STORE variants that explicitly do no bound checks, which > can be used by tools. I was thinking of adding CSTORE and CLOAD Uops (meaning either Checked or Client), so that LOAD and STORE can be used on any address. > * Add a flag to LOAD/STORE if a boundcheck should explicitly avoided. This is an option too, but it seems to be a significant enough difference to allocate a Uop for it. I wonder if tools will ever want to generate FP/SSE instructions? At the moment, they're always checked too. > 1171 done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG_(dispatch_ctr) -1; > 1172 vg_assert(done_this_time >= 0); > > done_this_time should be the number of BB executed in the inner loop, isn't > it? But why the "-1" ? Somehow with "--pointercheck=no", done_this_time can > be -1 the first time, and thus the assertion failed. > So I simply removed the "-1". I think that assert fails if it didn't run even one basic block. That could be seen as a problem because you're not making any progress on your program. But I don't really know what the rationale for the assert is. However, it looks to me like that's a secondary symptom of some other problem. I assume this only happens with your tool, and not the rest. Can you see why it would be exiting the basic block early? Does --trace-signals=yes show any signals being delivered? > Now I get another SEGFAULT crash. Using gdb, I found out that in vg_dispatch.S > there is a check for clo_checkpointer,assuming a integer type, but Bool is a > "unsigned char". Change the 2 checks, e.g. the first check to > > movb VG_(clo_pointercheck), %al > testb %al,%al > > , and valgrind runs fine with --pointercheck=no. > Even my skin runs fine now. That's a bit embarrassing. |