|
From: Josef W. <Jos...@gm...> - 2004-10-13 14:09:51
|
Hi,
with the arch-abstraction, a $PREFIX/include/valgrind/x86/tool_arch.h was
introduced, which is included by tool.h. This breaks compiling of at least my
external tool, which (currently) only has $PREFIX/include/valgrind in the
include path.
What is the best way to solve this?
1) The tool has to find out the architecture itself, and adds the needed
include path.
2) Valgrind installs an architecture specific include configuration.
2.1) Install tool_arch.h into $PREFIX/include/valgrind.
2.2) Symlink to $PREFIX/include/valgrind/x86/tool_arch.h
2.3) Modify tool.h to include "x86/tool_arch.h"
2.4) External tool uses `pkg-config --cflags valgrind`
For all 2.x) solutions: Is the assumption correct that Valgrind installations
are for one architecture only? I think so.
If yes, I am for 2.4).
Proposed patch for valgrind.pc.in
--- valgrind.pc.in.orig 2004-10-13 16:05:14.343322440 +0200
+++ valgrind.pc.in 2004-10-13 16:05:34.859203552 +0200
@@ -8,4 +8,4 @@
Version: @VERSION@
Requires:
Libs:
-Cflags: -I${includedir}
+Cflags: -I${includedir} -I${includedir}/@VG_ARCH@
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-13 14:28:14
|
On Wed, 13 Oct 2004, Josef Weidendorfer wrote:
> 2.4) External tool uses `pkg-config --cflags valgrind`
>
> For all 2.x) solutions: Is the assumption correct that Valgrind installations
> are for one architecture only? I think so.
Certainly in the short and medium term.
> If yes, I am for 2.4).
>
> Proposed patch for valgrind.pc.in
> --- valgrind.pc.in.orig 2004-10-13 16:05:14.343322440 +0200
> +++ valgrind.pc.in 2004-10-13 16:05:34.859203552 +0200
> @@ -8,4 +8,4 @@
> Version: @VERSION@
> Requires:
> Libs:
> -Cflags: -I${includedir}
> +Cflags: -I${includedir} -I${includedir}/@VG_ARCH@
So that's the only change I need to put into Valgrind to make you happy?
If so, that's no problem.
(I think I'll need -I${includedir}/@VG_PLATFORM@ too, now).
N
|
|
From: Josef W. <Jos...@gm...> - 2004-10-13 16:34:17
|
On Wednesday 13 October 2004 16:26, Nicholas Nethercote wrote:
> > --- valgrind.pc.in.orig 2004-10-13 16:05:14.343322440 +0200
> > +++ valgrind.pc.in 2004-10-13 16:05:34.859203552 +0200
> > @@ -8,4 +8,4 @@
> > Version: @VERSION@
> > Requires:
> > Libs:
> > -Cflags: -I${includedir}
> > +Cflags: -I${includedir} -I${includedir}/@VG_ARCH@
>
> So that's the only change I need to put into Valgrind to make you happy?
> If so, that's no problem.
Thanks.
Further wishes: -)
In Cachegrind, you added a x86 subdirectory for the CPUID stuff. I think it
would be good to move this to Valgrind itself and add a general function to
the tool API for requesting architecture features like cache sizes.
typedef enum { Vg_CacheI1Size, Vg_CacheI1Assoc,
VG_CacheI1LineSize, ... } VgArchFeature;
extern int VG_(get_arch_feature)(VgArchFeature, char* resultBuffer, int len);
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 I'll need -I${includedir}/@VG_PLATFORM@ too, now).
Probably.
Josef
>
> N
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-14 10:26:08
|
On Wed, 13 Oct 2004, Josef Weidendorfer wrote:
>>> -Cflags: -I${includedir}
>>> +Cflags: -I${includedir} -I${includedir}/@VG_ARCH@
>>
>> So that's the only change I need to put into Valgrind to make you happy?
>> If so, that's no problem.
>
> Thanks.
Done (and @VG_PLATFORM@ too).
> Further wishes: -)
> In Cachegrind, you added a x86 subdirectory for the CPUID stuff. I think it
> would be good to move this to Valgrind itself and add a general function to
> the tool API for requesting architecture features like cache sizes.
>
> typedef enum { Vg_CacheI1Size, Vg_CacheI1Assoc,
> VG_CacheI1LineSize, ... } VgArchFeature;
> extern int VG_(get_arch_feature)(VgArchFeature, char* resultBuffer, int len);
The difficulty here is that CPUID has so many different parts that it's
not obvious what the interface for querying it would look like.
N
|
|
From: Tom H. <th...@cy...> - 2004-10-13 16:41:11
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> In Cachegrind, you added a x86 subdirectory for the CPUID stuff. I think it
> would be good to move this to Valgrind itself and add a general function to
> the tool API for requesting architecture features like cache sizes.
>
> 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...
> 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?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Josef W. <Jos...@gm...> - 2004-10-13 20:43:28
|
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
|
|
From: Julian S. <js...@ac...> - 2004-10-14 10:49:00
|
> > > 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. An architecture-neutral IR is definitely under development and it will allow you to avoid arch-specifics in tools -- that is one of the design goals. For the cache profilers, all you want to see is (1) all load and store insns, including data sizes and addresses, and (2) where the boundaries between original client instructions are. I'm sure this will be possible with no great problems. J |