Re: [Valgrind-developers] Valgrind headers for external skins

[Josef W. <Jos...@gm...>]

On Wednesday 13 October 2004 18:40, Tom Hughes wrote:
> > typedef enum { Vg_CacheI1Size, Vg_CacheI1Assoc,
> > 	 VG_CacheI1LineSize, ... } VgArchFeature;
> > extern int VG_(get_arch_feature)(VgArchFeature, char* resultBuffer, int
> > len);
>
> I have to say that I'm not a huge fan of an interface as loosely
> typed as that...

Yes, you are right. Probably an interface similar to cachegrind/cg_arch.h
  typedef struct { int size, assoc, line_size; } cache_t;
  typedef enum { Vg_I1, Vg_L1, Vg_L2 } VgCacheType;
  cache_t get_cache_config(VgCacheType);
is better. But this seems to specific to be moved to Valgrind core.

Perhaps putting functions handy for similar tools into own libraries, linking 
these tools to them, and doing some dependency check with meanful error 
messages at startup (like version checking). Especially if these functions 
are architecture/platform specific, this would ease testing of tools 
dependent on common functionality.

>> > And regarding arch-abstraction, it would be cool to get rid of the
> > arch-specifics in tools whenever possible: E.g. in cachegrind (and
> > calltree also), there is the MMX/SSE stuff. Perhaps some functions could
> > be added providing additional high level properties for UOps like if it
> > is accessing memory and so on. Prove of concept would be a cachegrind
> > with same source for PowerPC, x86 and x86_64.
>
> I think that sort of thing comes under the heading of reworking UCode
> for better platform independence which I believe Julian is working on?

Yes, but reworking UCode is quite difficult to get it right. But this seems to 
be a worthwhile short-term goal. Perhaps here also, a library between 
Valgrind and the tool (as proposed above) is the best for this kind of thing.

Josef

>
> Tom