|
From: Yao Qi <qiy...@cn...> - 2006-02-23 05:32:09
|
I would like to send this request to maillist for an open discussion. Geoff Smith proposed an idea about Instruction Trace at http://sourceforge.net/mailarchive/message.php?msg_id=14760370 and I would like to explain and advocate his proposal. We started to write this tool in December 2005, and finish the prototype based on valgrind-3.1.0 until now. valgrind-itrace could trace actually executed instructions and record memory access, and output the result in a simple plain text format. It would work on X86 and PPC32 well. On the other hand, itrace/it_main.c is simple, less 500 lines, so it could be understood easily and help developers understand Valgrind internals. In this survey http://valgrind.org/gallery/survey_05/report.txt, it is said that, Profiling: - the possibility to perform the combination of instruction, syscall, and cache instrumentation. 1 Simulation correctness/robustness - Better instruction set coverage 5 function call tracer 3 so itrace in valgrind could do something relative to that above, and we are interested in contributing it to valgrind community and continue to improve its code , test cases and document. I do appreciate your comments at your earliest convenience, and I will submit a patch if you are willing to have a look on it. Thanks! -- Regards, Yao ------------ Yao Qi |
|
From: Josef W. <Jos...@gm...> - 2006-02-23 18:01:38
|
On Thursday 23 February 2006 06:31, Yao Qi wrote: > I would like to send this request to maillist for an open discussion. > > Geoff Smith proposed an idea about Instruction Trace at > http://sourceforge.net/mailarchive/message.php?msg_id=14760370 > and I would like to explain and advocate his proposal. It seems to me that lackey does already a lot of it, especially with the --trace-mem=yes option in Valgrind SVN (or was this already in 3.1? "--help" does not talk about it). Perhaps it is a better idea to add the missing things to lackey? AFAICS things missing in lackey wrt itrace: - print PC together with memory accesses (--trace-instr=yes) - enable detailed access trace only for some function(s) Josef |
|
From: Geoff S. <gs...@us...> - 2006-02-24 09:03:41
|
> > I would like to send this request to maillist for an open discussion. > > > > Geoff Smith proposed an idea about Instruction Trace at > > http://sourceforge.net/mailarchive/message.php?msg_id=14760370 > > and I would like to explain and advocate his proposal. > > It seems to me that lackey does already a lot of it, especially with > the --trace-mem=yes option in Valgrind SVN (or was this already in > 3.1? "--help" does not talk about it). > > Perhaps it is a better idea to add the missing things to lackey? > AFAICS things missing in lackey wrt itrace: > - print PC together with memory accesses (--trace-instr=yes) > - enable detailed access trace only for some function(s) If lackey actually does -trace-mem, simply adding -trace-instr seems like a natural. We actually used lackey as the model for the itrace tool. I can think of a couple reasons not to monkey with lackey: a.) lackey's ouput is completely oriented toward generating a summary (at least if you only consider documented options <g>); b.) don't want to gum up the "model" tool The only serious qualm I might have with --trace-instr is that we'd like to keep the output both terse (small) and easily parsable. Ideally, you could write an awk script to do simple analysis. (I haven't seen any trace-mem sample output yet, I should get a chance in the morning.) |
|
From: Josef W. <Jos...@gm...> - 2006-02-24 09:26:47
|
On Friday 24 February 2006 10:04, Geoff Smith wrote: > If lackey actually does -trace-mem, simply adding -trace-instr seems like > a natural. We actually used lackey as the model for the itrace tool. > > I can think of a couple reasons not to monkey with lackey: a.) lackey's > ouput is completely oriented toward generating a summary (at least if you > only consider documented options <g>); That seems to be already violated: IMHO, lackey is already advanced tutorial stuff about detecting memory accesses from VEX code. And summary vs. trace output makes not a huge difference for a valgrind tool example. I did not see the source if itrace yet, but a problem to integrate it with lackey would be if you have a lot of corner cases needing some special handling, which would make it a bad tutorial. > b.) don't want to gum up the > "model" tool Perhaps it would be a better idea to additionally have a really easy tool as tutorial; but perhaps this already is provided with the "none" tool? Another "model" I like to see is for how to make an external tool, which can be distributed separatly from VG source, with its own configure, using installed VG include files and linking to installed VG libs. > The only serious qualm I might have with --trace-instr is that we'd like > to keep the output both terse (small) and easily parsable. Something like --trace-mem is probably always used for postprocessing. So easy parsing should be mandatory. I think that Nick added memory access tracing because this is kind of a FAQ, and people can use lackey as starting point (similar as you did). Josef |
|
From: Yao Qi <qiy...@cn...> - 2006-02-24 12:30:15
Attachments:
valgrind-3.1.0-itrace-notests.diff
|
On Fri, Feb 24, 2006 at 10:26:37AM +0100, Josef Weidendorfer wrote: > > That seems to be already violated: IMHO, lackey is already advanced tutorial stuff > about detecting memory accesses from VEX code. > And summary vs. trace output makes not a huge difference for a valgrind tool > example. The output is simple, just record every instruction and memory access, but two options in itrace are attractive, --trace-function and --trace-calltree. The former could enable itrace to filter the output and only record instructions in this function you specified, while the latter could enable itrace to record all instructions in this function and instructions in functions called by this function. For example, mostly, we are only interested in instructions in one function, they two could filter the output and only display what you want. > I did not see the source if itrace yet, but a problem to integrate it with > lackey would be if you have a lot of corner cases needing some special > handling, which would make it a bad tutorial. itrace/it_main.c is well-commented and less than 500 lines, and the code itself is simple and neat! We start itrace from lackey, and we could integrate itrace with lackey without breaking its simplicity and readability. I include a patch of valgrind-itrace in attachment, and please apply it to valgrind-3.1.0. [qiyao@plinuxt6 valgrind-3.1.0]$ patch -p1 < ../valgrind-3.1.0-itrace-notests.diff patching file configure.in patching file Makefile.am patching file docs/xml/manual.xml patching file itrace/docs/it-manual.xml patching file itrace/docs/Makefile.am patching file itrace/it_main.c patching file itrace/Makefile.am patching file itrace/tests/Makefile.am I did not add test cases into this patch, and I will submit them later when needed! -- Regards, Yao ------------ Yao Qi |
|
From: Josef W. <Jos...@gm...> - 2006-02-24 22:42:43
|
Hi, it had a short look over the code. On Friday 24 February 2006 13:29, Yao Qi wrote: > The output is simple, just record every instruction and memory access, > but two options in itrace are attractive, --trace-function and > --trace-calltree. The former could enable itrace to filter the output So you print out all instructions where debug info says that they are in this function, right? You decide this in the callback function, which is run for every instruction in the code. Why not decide this already in the instrumentation phase? > and only record instructions in this function you specified, while the > latter could enable itrace to record all instructions in this function > and instructions in functions called by this function. I am not sure if this very simple calltree tracing is the right thing to include into VG source. At least there should be a big warning in the code/docu that this does not work * with multithreaded code (switching to another thread while in the function will leave you with tracing on) * with signal handlers (which will be traced, too) * with functions which are left via a jump (_dl_runtime_resolve, longjmps, perhaps exception handling, handcrafted assembler ...) * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the jumpkind is only a hint here as PPC has no explicit RET instructions) > I include a patch of valgrind-itrace in attachment, and please apply it > to valgrind-3.1.0. I am not the one to decide this, but I think it probably would be nice to add instruction tracing and function filtering (done at instrumentation time) to lackey. Why do you not simply provide an external tool package? You can look at the configure.in and Makefile.am's in callgrind which does exactly this (granted, with some problems regarding biarch support). Josef |
|
From: Yao Qi <qiy...@cn...> - 2006-02-27 10:17:52
|
On Fri, Feb 24, 2006 at 11:42:29PM +0100, Josef Weidendorfer wrote: > Hi, > > it had a short look over the code. > > So you print out all instructions where debug info says that they > are in this function, right? You decide this in the callback Yes, you are right! > function, which is run for every instruction in the code. > Why not decide this already in the instrumentation phase? At first, we did put all the instruction display in the instrumentation phase, but later, when we want to collect the information about memory access, data and address, I found that some data and address are generated at run time, so I had to put print_write_data() and print_read_data() in a callback form at run-time to collect some run-time information. I think this would decrease the efficiency of valgrind and itrace, but I could not find another better solution to it. In order to keep the order of instruction display and memory access display, that is to say, "R" or "W" record follow closedly to "I" or "J" record if this instruction access memory, I put print_instruction() into callback. Otherwise, instructions will be displayed first at instrumentation phase, and memory access will be displayed later at the run time, it would destroy the readability of the final output. If anyone here any better idea or comments to this, feel free to tell us. > > > and only record instructions in this function you specified, while the > > latter could enable itrace to record all instructions in this function > > and instructions in functions called by this function. > > I am not sure if this very simple calltree tracing is the right thing to > include into VG source. At least there should be a big warning in the > code/docu that this does not work > * with multithreaded code (switching to another thread while in the function > will leave you with tracing on) > * with signal handlers (which will be traced, too) > * with functions which are left via a jump (_dl_runtime_resolve, longjmps, > perhaps exception handling, handcrafted assembler ...) > * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the > jumpkind is only a hint here as PPC has no explicit RET instructions) We did few tests on above you mentioned, so we are not sure what would happen when itrace tracing a multithreaded program, a signal handler and exception handler. We will pay attention on these aspects and update the document per the test result! > > I include a patch of valgrind-itrace in attachment, and please apply it > > to valgrind-3.1.0. > > I am not the one to decide this, but I think it probably would be nice to add > instruction tracing and function filtering (done at instrumentation time) > to lackey. We would like to have try to port the code of itrace to lackey! > > Why do you not simply provide an external tool package? You can look at > the configure.in and Makefile.am's in callgrind which does exactly this > (granted, with some problems regarding biarch support). > > Josef -- Regards, Yao ------------ Yao Qi |
|
From: Geoff S. <gs...@us...> - 2006-02-25 01:03:11
|
I took a look at the valgrind --tool=lackey --trace-mem=yes output. With the trace-mem implementation, adding instruction tracing here seems to make sense. So I'd like to propose two alternatives. Alternative A. A separate itrace tool, as I proposed in http://sourceforge.net/mailarchive/message.php?msg_id=14760370 Alternative B. Dovetailing itrace into lackey as follows. The biggest impact to lackey would be adding the option --trace-instr=, and changing the output format to the record-oriented one I proposed before. This would reduce volume of output while keeping postprocessing easy. I would change chapter 9 of the user manual as follows: ------------------------------------------------------ 9. LACKEY, a very simple profiler and trace tool To use this tool, specify --tool=lackey on the Valgrind command line. Lackey is a simple Valgrind tool that provides a simple trace capability and some basic program measurement. It adds quite a lot of simple instrumentation to the program's code. It is primarily intended to be of use as an example tool. _Tracing Output_ Tracing output (if specified) is generated during program execution. Lackey can provide a trace of each instruction that is executed in your program, or a trace of memory accesses, or both by showing memory accesses associated with each instruction. _Profiling Output_ Lackey reports profiling information at the conclusion of program execution. The report includes: o The number of calls to the function specified by --fnname switch o The number of conditional branches encountered and the number and proportion of those taken. o Statistics about the amount of work done during the execution of the client program: o The number of basic blocks entered and completed by the program. Note that due to optimisations done by the JIT, this is not really an accurate value. o The number of guest (x86, amd64, ppc, etc.) instructions and IR statements executed. IR is Valgrind's RISC-like intermediate representation via which all instrumentation is done. o Ratios between some of these counts. 9.2 Command-line options specific to lackey --fnname=<name> Specifies the function to profile (and trace). The default is _dl_runtime_resolve(), the function in glibc's dynamic linker that resolves function references to shared objects. --trace-extent=all,function,calltree Specifies whether to trace the entire program, the instructions in the function specified by --fnname, or all instructions from entry into the function until the function returns. The default is calltree. --trace-instrs=yes Enables tracing of instructions. --trace-mem=yes Enables tracing of memory accesses. --detailed-counts=yes Profiling output includes a table with counts of loads, stores and ALU operations for various types of operands. The types are identified by their IR name ("I1" ... "I128", "F32", "F64", and "V128"). Also prints the exit code of the client program. 9.3 Trace Output The trace output consists of an ASCII-formatted trace of the instructions executed. The format is very simple to facilitate post-processing. The first character of each line ("record") indicates what kind of data is included in the line. Trace output is provided only if enabled. --trace-instr enables H, I, J, and G records. --trace-mem=yes enables H, R, and W records. Example ("..." indicates skipped records) ==14778== valgrind-itrace, Instruction and memory tracer. ==14778== Copyright (C) 2005, and GNU GPL'd. ==14778== Using LibVEX rev 1471, a library for dynamic binary translation. ==14778== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==14778== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==14778== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14778== For more details, rerun with: -v ==14778== H valgrind-itrace J 00244C67 55 ; dl_start ... J 08048394 55 ; main W BE8619A8 BE861A08 I 89E5 I 83EC08 I 83E4F0 I B800000000 I 83C00F I 83C00F I C1E804 I C1E004 I 29C4 I E8C7FFFFFF W BE86198C 080483B5 G J 0804837C 55 ; print W BE861988 BE8619A8 I 89E5 ... Record definitions H whatever ... Indicates the start of the trace, possibly with additional data in no specific format. J aaaa xxxx [; symbol] Instruction-with-address record. aaaa is the address of the instruction, xxxx is a byte dump of the instruction itself. All values are in hex. Optionally, a symbol name associated with the address may be provided. Note that "J" does not imply that a branch occurred, it merely indicates that the record includes the address of the instruction executed. I xxxx Instruction record for an instruction that immediately follows the previous instruction. The address can be determined from the length of the preceding instruction. G Indicates a gap in the trace. This will happen, for instance, when valgrind simulates a system call via an int 80 (on x86) or sc (on ppc) instruction, or when a branch occurs to code not being traced. R aaaaaaaa rrrr W aaaaaaaa wwwwwwww Indicates that the previous instruction caused a read of the bytes rrrr at the address, or a write of bytes wwww. The length of the read or write is indicated by the number of bytes shown. R and W records occur in logical order; for instance, an increment-memory instruction will show the read followed by the write. 9.4 Limitations Lackey runs quite slowly, especially when --detailed-counts=yes is specified. It could be made to run a lot faster by doing a slightly more sophisticated job of the instrumentation, but that would undermine its role as a simple example tool. Hence we have chosen not to do so. Memory tracing cannot catch every load and store access. See section 3.3.7 of Nicholas Nethercote's PhD dissertation "Dynamic Binary Analysis and Instrumentation", 2004, for details about the few loads and stores that is misses, and other caveats about the accuracy of the memory trace. When --trace-extent=calltree is specified, the tracing will stop only when the function returns to its caller. Tracing will not stop if the function does not return to its caller. Some examples of this are raising C++ or Ada exceptions and longjump. Also, signals and task switching may cause unexpected code to be included in the trace. |
|
From: Julian S. <js...@ac...> - 2006-02-28 13:39:35
|
> Alternative B. Dovetailing itrace into lackey as follows. The biggest > impact to lackey would be adding the option --trace-instr=, and changing > the output format to the record-oriented one I proposed before. This > would reduce volume of output while keeping postprocessing easy. I prefer Alternative B, with the following caveat. This change (add tracing) continues to move Lackey away from its original purpose - a very simple example tool - and instead changes it into a fairly simple tool which does basic instruction set stuff - insn counts, memory access counts, IR operation counts, trace generation. That's ok by me. However: As it stands the count generation stuff is appallingly inefficient because there are way too many helper function calls. This made sense when the purpose was to be a simple example tool, but it makes operation counting run very slowly. For example, a helper function is called once per insn executed, to increment the insns-executed counter. With little effort this could be changed to be incremented by N when a straight-line sequence of N insns is run. The problem is even more acute for counting IR operations since they are more numerous than guest instructions. > --trace-extent=all,function,calltree > > Specifies whether to trace the entire program, the instructions in the > function specified by --fnname, or all instructions from entry into the > function until the function returns. The default is calltree. I understand 'all' and 'function', but not 'calltree'. You mean 'function and children' ? J |
|
From: Nicholas N. <nj...@cs...> - 2006-02-28 22:29:23
|
On Tue, 28 Feb 2006, Julian Seward wrote:
> This change (add tracing) continues to move Lackey away from its
> original purpose - a very simple example tool - and instead changes
> it into a fairly simple tool which does basic instruction set stuff
> - insn counts, memory access counts, IR operation counts,
> trace generation. That's ok by me.
It's ok by me too, because it should be possible to keep the parts
relatively separate, but having command lines like --do-tracing, and so you
can use it as a multi-part tutorial where the parts are effectively
delineated by "if (clo_do_tracing) { ... }" conditions.
Nick
|
|
From: Geoff S. <gs...@us...> - 2006-03-01 00:14:32
|
> > This change (add tracing) continues to move Lackey away from its
> > original purpose - a very simple example tool - and instead changes
> > it into a fairly simple tool which does basic instruction set stuff
> > - insn counts, memory access counts, IR operation counts,
> > trace generation. That's ok by me.
>
> It's ok by me too, because it should be possible to keep the parts
> relatively separate, but having command lines like --do-tracing, and so
you
> can use it as a multi-part tutorial where the parts are effectively
> delineated by "if (clo_do_tracing) { ... }" conditions.
OK, in the absence of other comments, we will proceed along this path.
We'll make a couple of wording changes as well, as suggested by the
discussion on this.
|
|
From: Yao Qi <qiy...@cn...> - 2006-03-06 08:02:28
Attachments:
lk_main.c.diff
|
> > I understand 'all' and 'function', but not 'calltree'. You mean 'function > and children' ? Yes, 'calltree' means 'function and its children'! Here is a patch for lackey/lk_main.c to add instruction trace in Lackey and in order to keep lackey as simple and readable as possible, we do not consider too much about efficiency. If anyone has some suggestions about efficiency improvement, feel free to tell me. Would anyone here like to take a look? Any suggestions and comments are greatly appreciated! Thanks in advance! -- Regards, Yao ------------ Yao Qi |
|
From: Josef W. <Jos...@gm...> - 2006-03-06 20:17:12
|
Hi,
On Monday 06 March 2006 09:01, Yao Qi wrote:
> +static void print_data (Addr addr, HWord size, IREndness end)
> {
> - VG_(printf)("load : %p, %d\n", addr, size);
> ...
Why not keep the data size as part of the output for a memory access?
I see that the size can be computed from the length of the data, which is p=
rinted
at the end; but it is easier to look at a real number, and to parse it eg. =
with a
PERL script...
> +static VG_REGPARM(3) void trace_load(Addr addr, SizeT size, IREndness en=
d)
Hmm...
Why adding this additional parameter "end" to every load/store callback?
Isn't the endiness supposed to be constant at least in one program run?
In general it is always better for performance to do as little as possible
in a callback, therefore this remark (which is not really relevant here).
I just see that it is not easy (or even impossible?) to get the guest=20
endiness at instrumentation time.
Julian: Why was this done this way? Wouldn't it be better to add the
guest endiness to VexGuestLayout instead of (redundantly) to every
Load/Store IR?
> +static void print_jumpkind(Int kind)
> +{
> + =C2=A0/* Print Jump Kind. You could print what you like later. */
> + =C2=A0switch (kind)
> + =C2=A0 =C2=A0{
> + =C2=A0 =C2=A0case Ijk_Boring:
> + =C2=A0 =C2=A0case Ijk_TInval:
> + =C2=A0 =C2=A0case Ijk_Ret:
> + =C2=A0 =C2=A0case Ijk_Call:
> + =C2=A0 =C2=A0case Ijk_Sys_syscall:
> + =C2=A0 =C2=A0case Ijk_Sys_int128:
> + =C2=A0 =C2=A0case Ijk_Sys_int32:
> + =C2=A0 =C2=A0case Ijk_Sys_sysenter:
> + =C2=A0 =C2=A0case Ijk_EmWarn:
> + =C2=A0 =C2=A0 =C2=A0VG_(printf)("G\n");
What is the semantic of "G"? If it is "gap in instruction stream", Boring/R=
et/Call
probably should not output it.
> + =C2=A0VG_(printf)("%c ", instr_record);
> + =C2=A0/* Print instruction address. */
> + =C2=A0if (instr_record =3D=3D 'J')=20
> + =C2=A0 =C2=A0{
> + =C2=A0 =C2=A0 =C2=A0VG_(printf)("%p ", instruction);
> + =C2=A0 =C2=A0 =C2=A0instr_record =3D 'I';
> + =C2=A0 =C2=A0}
> + =C2=A0else VG_(printf)("%p ", instruction);
What is the difference between "I" and "J"? I seem to remember that "J" sho=
uld print
the address. I think it would be better to only have one format here: alway=
s print the
instruction address. IMHO it is better to not confuse a tutorial with such =
issues. The
idea of "instr_record" really is difficult to grasp.
> + =C2=A0if (VG_(get_fnname_if_entry)(instruction, func_name_buf,sizeof(fu=
nc_name_buf)))
> + =C2=A0 =C2=A0VG_(printf)(" ; %s",func_name_buf);
This is quite expensive to do for every instruction executed. And it is rea=
lly easy
to move to instrumentation time: provide a flag "this is a function entry" =
to the callback.=20
> + =C2=A0 /* Only collect the sequential instructions in one BB to make su=
re
> + =C2=A0 =C2=A0 =C2=A0that all the instructions in one BB are sequential.=
*/
> + =C2=A0 if (lk_clo_trace_instrs)
> + =C2=A0 =C2=A0 VG_(clo_vex_control).guest_chase_thresh =3D 0;
Why is this important to the tool?
> + =C2=A0 VG_(printf)("H vaglrind-itrace\n");
And this?
Josef
|
|
From: Julian S. <js...@ac...> - 2006-03-06 21:50:01
|
> > +static VG_REGPARM(3) void trace_load(Addr addr, SizeT size, IREndness
> > end)
>
> Hmm...
> Why adding this additional parameter "end" to every load/store callback?
> Isn't the endiness supposed to be constant at least in one program run?
> In general it is always better for performance to do as little as possible
> in a callback, therefore this remark (which is not really relevant here).
Certainly it's true that the 'end' parameter is unnecessary since all=20
IR loads/stores contain the endianness, so you can just call load_le=20
or load_be like in memcheck.=20
> I just see that it is not easy (or even impossible?) to get the guest
> endiness at instrumentation time.
Huh? Not so; see above.
> Julian: Why was this done this way? Wouldn't it be better to add the
> guest endiness to VexGuestLayout instead of (redundantly) to every
> Load/Store IR?
Because it means the meaning of any IR load/store can be then known=20
just by inspecting the load/store, and not looking at any other info.
Anyway, who says the guest only has one endianness? On ppc we have
(eg) lwz and lwbrx, which give both endiannesses.
> > +static void print_jumpkind(Int kind)
> > +{
> > + =C2=A0/* Print Jump Kind. You could print what you like later. */
> > + =C2=A0switch (kind)
> > + =C2=A0 =C2=A0{
> > + =C2=A0 =C2=A0case Ijk_Boring:
> > + =C2=A0 =C2=A0case Ijk_TInval:
> > + =C2=A0 =C2=A0case Ijk_Ret:
> > + =C2=A0 =C2=A0case Ijk_Call:
> > + =C2=A0 =C2=A0case Ijk_Sys_syscall:
> > + =C2=A0 =C2=A0case Ijk_Sys_int128:
> > + =C2=A0 =C2=A0case Ijk_Sys_int32:
> > + =C2=A0 =C2=A0case Ijk_Sys_sysenter:
> > + =C2=A0 =C2=A0case Ijk_EmWarn:
> > + =C2=A0 =C2=A0 =C2=A0VG_(printf)("G\n");
>
> What is the semantic of "G"? If it is "gap in instruction stream",
> Boring/Ret/Call probably should not output it.
I agree.
Also TInval should not output it, since that's just the implementation
for 'icbi'. You need to define what "gap in instruction stream"
really means. A system call?
> > + =C2=A0if (VG_(get_fnname_if_entry)(instruction,
> > func_name_buf,sizeof(func_name_buf))) + =C2=A0 =C2=A0VG_(printf)(" ;
> > %s",func_name_buf);
>
> This is quite expensive to do for every instruction executed. And it is
> really easy to move to instrumentation time: provide a flag "this is a
> function entry" to the callback.
Agree.
J
|
|
From: Josef W. <Jos...@gm...> - 2006-03-06 23:15:56
|
On Monday 06 March 2006 22:49, you wrote: > Certainly it's true that the 'end' parameter is unnecessary since all > IR loads/stores contain the endianness, so you can just call load_le > or load_be like in memcheck. > > > I just see that it is not easy (or even impossible?) to get the guest > > endiness at instrumentation time. > > Huh? Not so; see above. Ah, sorry, yes. I was confused. So to clarify (for myself, too): to get rid of the endianness parameter in the callback, one would write two versions of the callback, one for BE and one for LE, and instrument a callback to the correct version depending on the endianness given for the IR. > Because it means the meaning of any IR load/store can be then known > just by inspecting the load/store, and not looking at any other info. Agree. Simply forget my confused suggestion :-) > Anyway, who says the guest only has one endianness? On ppc we have > (eg) lwz and lwbrx, which give both endiannesses. Ah, thanks. I did not know. Josef |
|
From: Geoff S. <gs...@us...> - 2006-03-07 14:32:46
|
On the "semantics for G" -- The purpose of "G" is to inform a post-processing tool that there are instructions executed but not shown. The reason we added it is to tell the pipeline analyzer (our home-grown tool that uses this input) that the instruction following "G" does not literally follow the instruction before it. The tool can flush the pipeline model so you don't get misleading data. The point of "I" vs. "J" records was to keep the size of a trace down. Originally, we always collected traces of the entire execution; now that we can do calltrees, this is probably a less urgent need. The same reason why we just output the data in "R" and "W", not the size, too. The format should be simple enough that Perl should be able to handle it -- even awk can do it. I tried to explain the records in http://sourceforge.net/mailarchive/message.php?msg_id=14916512 |
|
From: Yao Qi <qiy...@cn...> - 2006-03-18 06:37:48
Attachments:
lk_main.c.diff
|
We made some changes in valgrind/lk_main.c per your comments in last week. Here is a list for the changes, 1) Add new jumpkind according to VEX/put/libvex_ir.h in trunk. 2) Move some code from run-time phase to instrumentation phase. 3) Separate memory access helpers to get rid of the endianness parameter. Here is a patch in attachment! -- Regards, Yao |
|
From: Yao Qi <qiy...@cn...> - 2006-03-24 10:28:59
Attachments:
lk-manual.xml.diff
|
There is another patch to valgrind/lackey/lk-manual.xml -- Regards, Yao ------------ Yao Qi |
|
From: Yao Qi <qiy...@cn...> - 2006-04-10 07:45:18
|
Could anyone have a look at these two patches? http://sourceforge.net/mailarchive/message.php?msg_id=15129677 http://sourceforge.net/mailarchive/message.php?msg_id=15202377 -- Regards, Yao ------------ Yao Qi |
|
From: Yao Qi <qiy...@cn...> - 2006-03-08 11:06:55
|
On Mon, Mar 06, 2006 at 09:17:00PM +0100, Josef Weidendorfer wrote:
>
> What is the semantic of "G"? If it is "gap in instruction stream", Boring/Ret/Call
> probably should not output it.
Yes, "G" means "gap in instruction stream", that is to say, there are
unshown instructions in the output. Now, there would be a "G" record in
output when one of the two cases occurred,
1 System Call. If the jumpkind of each BB is Ijk_Sys*, there is an
syscall instruction in instruction stream.
2 --trace-extent=function. If lackey *only* trace this function,
instructions in the function's children are ignored, so print "G" to
tell post-processor that there are some instructions unshown in the final
output. For example,
foo()
{
...
bar();
...
}
if the command line option to lackey is "--trace-extent=function
--fnname=foo", lackey will not trace the instructions in function bar(),
and there would be a "G" after instruction "call bar" or "blr bar".
> This is quite expensive to do for every instruction executed. And it is really easy
> to move to instrumentation time: provide a flag "this is a function entry" to the callback.
> > + ?? /* Only collect the sequential instructions in one BB to make sure
> > + ?? ?? ??that all the instructions in one BB are sequential. */
> > + ?? if (lk_clo_trace_instrs)
> > + ?? ?? VG_(clo_vex_control).guest_chase_thresh = 0;
>
> Why is this important to the tool?
I set VG_(clo_vex_control).guest_chase_thresh = 0 in order to make all
the instructions in one BB are sequent in address, separate un-sequent
instructions in different BB, and to avoid more than one instructions
are function entry.
If do not set VG_(clo_vex_control).guest_chase_thresh = 0, there may
be more than one function-entry instructions in one BB, but there is
only one buffer for function name, so we have to "split" the BB as small
as possible to make sure only one function-entry instruction in one BB.
Any better ideas or thoughts to this issue are appriciated!
>
> > + ?? VG_(printf)("H vaglrind-itrace\n");
>
> And this?
This is just a header for output.
>
>
--
Regards, Yao
------------
Yao Qi
|