|
From: Josef W. <Jos...@gm...> - 2005-07-27 09:57:58
|
Hi,
thanks to installing the vex headers, and so on, I am able to compile my
standalone tool now (after a fresh VG3 installation), and it is actually
working on x86 with and without cache simulation (ls, xclock).
Next thing I try to make it work is on AMD64, but here are some
comments/questions:
* for VG_(getcwd_alloc), which is defined in pub_tool_libcfile.h as part of
the tool API, there is no implementation
* is VG_(clo_pointercheck) used at all? I used to have to set it to False to
be able to run my tool (I instrument code which writes to valgrind space).
Is this check (whether a store is into client space) really currently done?
* I used to track VG_(track_thread_run) to be able to regularly poll for
existiance of a "command file". This is my way to be able to control the
simulation interactively, and this is quite a crucial feature. Currently, the
according stuff in m_threadmodel.c is commented out. Will this ever be
uncommented again? Or what is a better way to wait/poll for interactive
commands?
* REP: I took the instrumentation for memory access from Cachegrind (thanks!),
and there is the same problem:
...
0x3A967D6A: repe cmpsb
...
------ After instrumentation -------
...
------ IMark(0x3A967D6A, 2) ------
t1 = GET:I32(4)
t6 = CmpEQ32(t1,0x0:I32)
if (t6) goto {Boring} 0x3A967D6C:I32
t7 = Sub32(t1,0x1:I32)
PUT(4) = t7
t0 = GET:I32(48)
t4 = GET:I32(28)
t5 = GET:I32(24)
t2 = LDle:I8(t4)
t3 = LDle:I8(t5)
PUT(32) = 0x4:I32
t50 = 8Uto32(t3)
PUT(36) = t50
t51 = 8Uto32(t2)
PUT(40) = t51
PUT(44) = 0x0:I32
t10 = Add32(t4,t0)
PUT(28) = t10
t11 = Add32(t5,t0)
PUT(24) = t11
t52 = 32to8(t51)
t53 = 32to8(t50)
t21 = CmpEQ8(t53,t52)
t54 = 1Uto32(t21)
t55 = 32to1(t54)
t56 = Not1(t55)
if (t56) goto {Boring} 0x3A967D6C:I32
DIRTY 1:I1 ::: log_1I_1Dr_cache_access[rp=2]{0xB125958B}(0xB07D5C2C:I32,t5)
The call to log_1I_1Dr_cache_access is done outside the the loop.
This has to called before "if (t56) ..."
I am currently investigating the best way to do this. Nick, any idea?
* Something to add to cachegrind/cg-x86.c again. This gets rid of some ugly
warning about an unkown configuration on newer Pentium M (Dothan):
+++ cg-x86.c 2005-07-27 03:59:14.000000000 +0200
@@ -169,6 +169,10 @@
case 0x86: *L2c = (cache_t) { 512, 4, 64 }; L2_found = True; break;
case 0x87: *L2c = (cache_t) { 1024, 8, 64 }; L2_found = True; break;
+ /* prefetch info, ignore */
+ case 0xf0: case 0xf1:
+ break;
+
default:
VG_(message)(Vg_DebugMsg,
"warning: Unknown Intel cache config value "
Sure I'll send the next mail when AMD64 is working...
Cheers,
Josef
|
|
From: Tom H. <to...@co...> - 2005-07-27 11:01:51
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> Next thing I try to make it work is on AMD64, but here are some
> comments/questions:
>
> * for VG_(getcwd_alloc), which is defined in pub_tool_libcfile.h as part of
> the tool API, there is no implementation
It was removed by Nick in revision 3995:
Remove VG_(getcwd_alloc)(), which can be done otherwise pretty easily.
This halves m_libcfile's dependence on m_mallocfree.
Obviously the header should be fixed as well.
> * is VG_(clo_pointercheck) used at all? I used to have to set it to False to
> be able to run my tool (I instrument code which writes to valgrind space).
> Is this check (whether a store is into client space) really currently done?
It isn't currently enabled for any platform as far as I know. The
previous implementation was x86 specific anyway and won't work on amd64.
> * I used to track VG_(track_thread_run) to be able to regularly poll for
> existiance of a "command file". This is my way to be able to control the
> simulation interactively, and this is quite a crucial feature. Currently, the
> according stuff in m_threadmodel.c is commented out. Will this ever be
> uncommented again? Or what is a better way to wait/poll for interactive
> commands?
Some sort of thread modelling should hopefully come back...
We could just put VG_TRACK( thread_run, tid ) into the scheduler
for now, where it currently calls VG_(tm_thread_switchto).
> * Something to add to cachegrind/cg-x86.c again. This gets rid of some ugly
> warning about an unkown configuration on newer Pentium M (Dothan):
>
> +++ cg-x86.c 2005-07-27 03:59:14.000000000 +0200
> @@ -169,6 +169,10 @@
> case 0x86: *L2c = (cache_t) { 512, 4, 64 }; L2_found = True; break;
> case 0x87: *L2c = (cache_t) { 1024, 8, 64 }; L2_found = True; break;
>
> + /* prefetch info, ignore */
> + case 0xf0: case 0xf1:
> + break;
> +
> default:
> VG_(message)(Vg_DebugMsg,
> "warning: Unknown Intel cache config value "
I'll put that in when we're unfrozen if nobody else gets there first.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-07-27 16:17:20
|
On Wednesday 27 July 2005 13:01, Tom Hughes wrote: > In message <200...@gm...> > > * is VG_(clo_pointercheck) used at all? I used to have to set it to False > > to be able to run my tool (I instrument code which writes to valgrind > > space). Is this check (whether a store is into client space) really > > currently done? > > It isn't currently enabled for any platform as far as I know. The > previous implementation was x86 specific anyway and won't work on amd64. OK. So I will keep setting VG_(clo_pointercheck)=False in. It is better to get a compile error for the tool than a strange error message at runtime if there will be a valgrind release in the future without VG_(clo_pointercheck)... > > * I used to track VG_(track_thread_run) to be able to regularly poll for > > existiance of a "command file". This is my way to be able to control the > > simulation interactively, and this is quite a crucial feature. Currently, > > the according stuff in m_threadmodel.c is commented out. Will this ever > > be uncommented again? Or what is a better way to wait/poll for > > interactive commands? > > Some sort of thread modelling should hopefully come back... > > We could just put VG_TRACK( thread_run, tid ) into the scheduler > for now, where it currently calls VG_(tm_thread_switchto). Thanks for the hint. I looked at the scheduler, and I think it makes more sense to put VG_TRACK( thread_run, tid ) at end of VG_(set_running) instead of VG_(scheduler). Otherwise the tool does not notice some thread switches, as VG_(set_running) is called from VG_(vg_yield)(void), too. I think it is exactly this bug I was bitten a few weeks ago: My tool was not able to reliable track thread switches, until I checked VG_(running_tid) every time. The problem was that after returning from a signal handler, execution resumed in another thread, but thread_run was not called. Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 17:14:05
|
On Wed, 27 Jul 2005, Tom Hughes wrote: >> * for VG_(getcwd_alloc), which is defined in pub_tool_libcfile.h as part of >> the tool API, there is no implementation > > It was removed by Nick in revision 3995: > > Remove VG_(getcwd_alloc)(), which can be done otherwise pretty easily. > This halves m_libcfile's dependence on m_mallocfree. > > Obviously the header should be fixed as well. I'll fix it after the freeze. I removed getcwd_alloc() so that m_libcfile.c wouldn't depend on on m_mallocfree.c. Josef, please use VG_(getcwd)() with a static buffer, as done in Cachegrind. >> * is VG_(clo_pointercheck) used at all? I used to have to set it to False to >> be able to run my tool (I instrument code which writes to valgrind space). >> Is this check (whether a store is into client space) really currently done? > > It isn't currently enabled for any platform as far as I know. The > previous implementation was x86 specific anyway and won't work on amd64. The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like it's doing something on x86. >> * I used to track VG_(track_thread_run) to be able to regularly poll for >> existiance of a "command file". This is my way to be able to control the >> simulation interactively, and this is quite a crucial feature. Currently, the >> according stuff in m_threadmodel.c is commented out. Will this ever be >> uncommented again? Or what is a better way to wait/poll for interactive >> commands? Was this a problem with 2.4.0 also? If not, what changed between 2.4.0 and 3.0.0? > Some sort of thread modelling should hopefully come back... > > We could just put VG_TRACK( thread_run, tid ) into the scheduler > for now, where it currently calls VG_(tm_thread_switchto). That sounds like a good solution. N |
|
From: Tom H. <to...@co...> - 2005-07-27 16:49:59
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Wed, 27 Jul 2005, Tom Hughes wrote:
>
>>> * is VG_(clo_pointercheck) used at all? I used to have to set it to False to
>>> be able to run my tool (I instrument code which writes to valgrind space).
>>> Is this check (whether a store is into client space) really currently done?
>>
>> It isn't currently enabled for any platform as far as I know. The
>> previous implementation was x86 specific anyway and won't work on amd64.
>
> The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like
> it's doing something on x86.
The segment limits are setup yes, but as VEX won't put a segment
prefix on any of the loads or stores it does that won't have any
effect will it?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 17:08:05
|
On Wed, 27 Jul 2005, Tom Hughes wrote: >> The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like >> it's doing something on x86. > > The segment limits are setup yes, but as VEX won't put a segment > prefix on any of the loads or stores it does that won't have any > effect will it? Oh yes, I think you're right. N |
|
From: Tom H. <to...@co...> - 2005-07-27 17:13:00
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <Pin...@ch...>
> Nicholas Nethercote <nj...@cs...> wrote:
>
>> The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like
>> it's doing something on x86.
>
> The segment limits are setup yes, but as VEX won't put a segment
> prefix on any of the loads or stores it does that won't have any
> effect will it?
Indeed, in 2.4.0 vg_from_ucode.c had code to add a %fs prefix to
memory accesses if pointer checks were enabled. There is no equivalent
to that in 3.0.0 so enabling pointer checks will do nothing.
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-07-27 19:15:10
|
On Wednesday 27 July 2005 15:35, Nicholas Nethercote wrote: > m_libcfile.c wouldn't depend on on m_mallocfree.c. Josef, please use > VG_(getcwd)() with a static buffer, as done in Cachegrind. Yes. > >> * I used to track VG_(track_thread_run) to be able to regularly poll for > >> existiance of a "command file". This is my way to be able to control the > >> simulation interactively, and this is quite a crucial feature. > >> Currently, the according stuff in m_threadmodel.c is commented out. Will > >> this ever be uncommented again? Or what is a better way to wait/poll for > >> interactive commands? > > Was this a problem with 2.4.0 also? If not, what changed between 2.4.0 > and 3.0.0? The problem with 3.0 currently is that a tool will never get thread_run called as it is commented out. In 2.4 it worked, there was no problem there. Or do I miss the point in your question? > > Some sort of thread modelling should hopefully come back... > > > > We could just put VG_TRACK( thread_run, tid ) into the scheduler > > for now, where it currently calls VG_(tm_thread_switchto). > > That sounds like a good solution. See the other mail. Shouldn't thread_run be called on any thread switch? Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 19:30:40
|
On Wed, 27 Jul 2005, Josef Weidendorfer wrote: >>> Some sort of thread modelling should hopefully come back... >>> >>> We could just put VG_TRACK( thread_run, tid ) into the scheduler >>> for now, where it currently calls VG_(tm_thread_switchto). >> >> That sounds like a good solution. > > See the other mail. Shouldn't thread_run be called on any thread switch? I don't understand the issues here. Josef, perhaps it would be best if you just write a patch for m_scheduler.c containing the code that you want? N |
|
From: Josef W. <Jos...@gm...> - 2005-07-27 21:55:12
|
On Wednesday 27 July 2005 21:30, Nicholas Nethercote wrote:
> On Wed, 27 Jul 2005, Josef Weidendorfer wrote:
> >>> Some sort of thread modelling should hopefully come back...
> >>>
> >>> We could just put VG_TRACK( thread_run, tid ) into the scheduler
> >>> for now, where it currently calls VG_(tm_thread_switchto).
> >>
> >> That sounds like a good solution.
> >
> > See the other mail. Shouldn't thread_run be called on any thread switch?
>
> I don't understand the issues here. Josef, perhaps it would be best if
> you just write a patch for m_scheduler.c containing the code that you
> want?
VG_(set_running)(ThreadId tid) is called from 2 places in scheduler.c:
(1) from VG_(vg_yield)(void)
(2) from VG_(scheduler) ( ThreadId tid )
Tom suggested to insert VG_TRACK( thread_run, tid ) into VG_(scheduler),
directly after the call to VG_(set_running). Unfortunately, this way a tool
misses thread switches triggered by VG_(vg_yield). So my suggestion is the
following:
--- scheduler.c.orig 2005-07-27 23:36:08.000000000 +0200
+++ scheduler.c 2005-07-27 15:47:26.000000000 +0200
@@ -203,6 +203,8 @@ void VG_(set_running)(ThreadId tid)
if (VG_(clo_trace_sched))
print_sched_event(tid, "now running");
+
+ VG_TRACK( thread_run, tid );
}
If we reestablish m_threadmodel.c, VG_(tm_thread_switchto) should be called
from VG_(set_running) to get both switch cases, and not only from
VG_(scheduler).
Regarding your question for VG 2.4: Yes, I have the problem there that my tool
is not reliable notified about all thread switched via thread_run.
Josef
>
> N
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|