|
From: Yao Qi <qiy...@cn...> - 2005-11-02 05:50:23
|
Hello,all, I am reading lackey/lk_main.c and I want to add some features to lackey. One thing I want to do is to get the name of the specified program in lackey, for example, ./coregrind/valgrind --tool=lackey hello How could lackey get the program name "hello"? I think stage1 and stage2 could do that, but I am not sure how to do that in a valgrind tool. Maybe someone of you could clarify for me. Thanks in advance. -- Regards, Yao Yao Qi |
|
From: Josef W. <Jos...@gm...> - 2005-11-02 09:04:15
|
On Wednesday 02 November 2005 06:50, Yao Qi wrote: > Hello,all, > > I am reading lackey/lk_main.c and I want to add some features to > lackey. One thing I want to do is to get the name of the specified > program in lackey, for example, > > ./coregrind/valgrind --tool=lackey hello > > How could lackey get the program name "hello"? I think stage1 and > stage2 could do that, but I am not sure how to do that in a valgrind > tool. Maybe someone of you could clarify for me. Thanks in advance. When writing a tool, you need to use functions/global variables defined in valgrinds tool API. For VG 3.x, the API is defined in the header files $prefix/include/valgrind/pub_tool_* For VG 2.x, it was $prefix/include/valgrind/vg_tool.h The concrete function (more exact: global variable) you ask for changed from VG 3.0.x to VG 3.1.x. For VG 3.0.x, it is VG_(client_argv)[0], defined in pub_tool_libcproc.h. For VG 3.1.x, it is VG_(args_the_exename), defined in pub_tool_clientstate.h. Josef |
|
From: Yao Qi <qiy...@cn...> - 2005-11-03 03:33:30
|
Josef Weidendorfer wrote: > On Wednesday 02 November 2005 06:50, Yao Qi wrote: > > > > When writing a tool, you need to use functions/global variables > defined in valgrinds tool API. For VG 3.x, the API is defined in the > header files $prefix/include/valgrind/pub_tool_* > For VG 2.x, it was $prefix/include/valgrind/vg_tool.h > > The concrete function (more exact: global variable) you ask > for changed from VG 3.0.x to VG 3.1.x. > For VG 3.0.x, it is VG_(client_argv)[0], defined in pub_tool_libcproc.h. > For VG 3.1.x, it is VG_(args_the_exename), defined in pub_tool_clientstate.h. > > Josef > Thanks for your kind help, VG_(client_argv)[0] is useful for me to get the file name in a tool. I have browsed source code and document for some days but I could not find this global variable. A document about valgrind tool API may be needed for valgrind tool developers to reference. I am thinking of the name and the format of this document, anyone could confirm or deny this? Thanks in advance! -- Regards, Yao Yao Qi |
|
From: Nicholas N. <nj...@cs...> - 2005-11-03 16:16:04
|
On Thu, 3 Nov 2005, Yao Qi wrote: > I have browsed source code and document for some days but I could not find > this global variable. A document about valgrind tool API may be needed > for valgrind tool developers to reference. I am thinking of the name and > the format of this document, anyone could confirm or deny this? The tool API is defined by the include/pub_tool_*.h files. There is some internal documentation in docs/internals/ which you may find useful, in particular module-structure.txt. The other files in that directory are a mixed bag of things that we decided were worth keeping. The documentation for writing tools is not good. It would be great to improve it. The hard part is keeping documentation up to date. Nick |
|
From: Yao Qi <qiy...@cn...> - 2005-11-04 11:43:03
|
Nicholas Nethercote wrote:
> On Thu, 3 Nov 2005, Yao Qi wrote:
>
>> I have browsed source code and document for some days but I could not
>> find
>> this global variable. A document about valgrind tool API may be needed
>> for valgrind tool developers to reference. I am thinking of the name and
>> the format of this document, anyone could confirm or deny this?
>
>
> The tool API is defined by the include/pub_tool_*.h files.
>
> There is some internal documentation in docs/internals/ which you may
> find useful, in particular module-structure.txt. The other files in
> that directory are a mixed bag of things that we decided were worth
> keeping.
Thanks for your kind help.
>
> The documentation for writing tools is not good. It would be great to
> improve it. The hard part is keeping documentation up to date.
Yes. I am puzzled by some points in docs/xml/writing-tools.xml, for example
include/tool.h. This file name appeared several times in this document, but I
could not find it in valgrind source code, although it is said that this file
has been split into a number of header files in include/.
I have modified some of them, and here go a patch for your reference.
Would you like to take a look? Any suggestions and comments are highly
appreciated!
Index: docs/xml/writing-tools.xml
===================================================================
--- docs/xml/writing-tools.xml (revision 4995)
+++ docs/xml/writing-tools.xml (working copy)
@@ -93,7 +93,7 @@
<para>A tool has no control over these operations; it never
"sees" the code doing this work and thus cannot instrument it.
However, the core provides hooks so a tool can be notified
- when certain interesting events happen, for example when when
+ when certain interesting events happen, for example when
dynamic memory is allocated or freed, the stack pointer is
changed, or a pthread mutex is locked, etc.</para>
@@ -114,7 +114,7 @@
tool to wrap system calls.</para>
</listitem>
<listitem>
- <para>Other: all other kernel activity (e.g. process
+ <para>Others: all other kernel activitives (e.g. process
scheduling) is totally opaque and irrelevant to the
program.</para>
</listitem>
@@ -181,7 +181,7 @@
(<computeroutput>_dl_runtime_resolve()</computeroutput>); the
number of basic blocks, x86 instruction, UCode instructions
executed; the number of branches executed and the proportion of
- those which were taken.</para>
+ them which were taken.</para>
</listitem>
</itemizedlist>
@@ -315,7 +315,8 @@
<para>To write your own tool, you'll need the Valgrind source code.
A normal source distribution should do, although you might want to
check out the latest code from the Subversion repository. See the
-information about how to do so at <ulink url="http://www.valgrind.org/">the
+information about how to do so at
+<ulink url="http://www.valgrind.org/downloads/repository.html">the
Valgrind website</ulink>.</para>
</sect2>
@@ -503,7 +504,7 @@
than doing error handling from scratch because the core is doing
most of the work. See the type
<computeroutput>VgNeeds</computeroutput> in
-<filename>include/tool.h</filename> for full details of all
+<filename>coregrind/pub_core_tooliface.h</filename> for full details of all
the needs.</para>
<para>Third, the tool can indicate which events in core it wants
@@ -523,7 +524,7 @@
<para>More information about "details", "needs" and "trackable
events" can be found in
-<filename>include/tool.h</filename>.</para>
+<filename>include/pub_tool_tooliface.h</filename>.</para>
</sect2>
@@ -688,8 +689,8 @@
<para>If you just want to know whether a program point has been
reached, using the <computeroutput>OINK</computeroutput> macro
-(in <filename>include/tool.h</filename>) can be easier than
-using GDB.</para>
+(in <filename>include/pub_tool_libcprint.h</filename>) can be easier
+than using GDB.</para>
<para>The other debugging command line options can be useful too
(run <computeroutput>valgrind -h</computeroutput> for the
@@ -808,7 +809,7 @@
</listitem>
<listitem>
- <para>Write the documentation. There are some helpful bits and
+ <para>Write the documentation. There are some helpful bits and
pieces on using xml markup in
<filename>valgrind/docs/xml/xml_help.txt</filename>.</para>
</listitem>
@@ -1124,8 +1125,8 @@
<computeroutput>VGP_POPCC</computeroutput> macros to record time
spent doing certain things. New profiling event numbers must not
overlap with the core profiling event numbers. See
-<filename>include/tool.h</filename> for details and Memcheck
-for an example.</para>
+<filename>include/pub_tool_profile.h</filename> for details and
+Memcheck for an example.</para>
</sect2>
--
Regards, Yao
Yao Qi
|
|
From: Tom H. <to...@co...> - 2005-11-04 12:08:39
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> Yes. I am puzzled by some points in docs/xml/writing-tools.xml, for example
> include/tool.h. This file name appeared several times in this document, but I
> could not find it in valgrind source code, although it is said that this file
> has been split into a number of header files in include/.
The tool.h file no longer exists - it has been split into separate
files for each module - the pub_tool_*.h files that Nick mentioned.
So you've found an out of date piece of documentation I'm afraid.
> I have modified some of them, and here go a patch for your reference.
> Would you like to take a look? Any suggestions and comments are highly
> appreciated!
I'll have a look at the patch. Thanks for supplying it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|