Re: [Valgrind-developers] Reinstate full functionality of lackey [PATCH]

[Jeroen N. W. <jn...@xs...>]

On Sun, 30 Oct 2005, Julian Seward wrote:
>
> Jeroen, great stuff.
>
>> >> - To count the number of guest instructions, I count the number of
>> >> Ist_IMark statements executed. Is this the correct approach?
>> >
>> > Yes.
>
> Yes, although you can (optionally) use a different strategy which is
> cheaper.  Rather than call add_one_guest_instr each time an IMark
> is passed, make the instrumentation loop increment a counter when
> it passes an IMark.  Then, either at the end of the BB or when you
> get to an Ist_Exit, call a (new) fn add_N_guest_instrs and pass it
> the counter.  Then reset the counter to zero.  In other words,
> call the instruction-counting function once for each piece of
> straight-line code.  Cachegrind uses a similar strategy.
>
> I'm not saying you should do this, considering lackey is supposed
> to be a simple tool example, but it is a possible go-faster option.
>

I don't like to burden Lackey with this, but I'll keep it in mind for the
next tool I'm working on: Blanket, a basic code coverage tool (mentioned
in '3.2.2. Suggested tools' in file docs/xml/writing-tools.xml).

> Depending on what Nick thinks, and your hacking enthusiasm, there is
> something that would make Lackey more useful whilst still being a
> nice simple demo of how to make a tool.  That is, generate counts
> for all the following events:
>
>   guest instructions
>   conditional branches (split into: taken, not taken)
>   loads   (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
>   stores  (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
>   alu ops (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
>
> Someone on the users list asked for something like this just the
> other day (Christian Stimming, "Fast profiling in valgrind?", 25 Oct).
> Personally I think it'd be a valuable addition.
>
> Not hard to do either: for stores, examine Ist_Store, and use
> typeOfIRExpr(bb->tyenv, st->Ist.Store.data) to get the store type.
> For loads and ALU ops, you only need to look at Ist_Tmp cases
> where the Ist.Tmp.data is either Iex_Load or Iex_{Unop,Binop}.
> All statements you will ever encounter will satisfy isFlatIRStmt
> which essentially constrains them to being flat SSA-style.
>

Done. See attached files lk_main.c and lk-manual.xml. This output is
generated only with command line option --show-guest-details=yes. To
achieve a nice format I had to hack coregrind/m_debuglog.c to:
- accept '*' as width specifier in format strings.
- fix the interpretation of VG_MSG_LJUSTIFY for strings, which was turned
around.
See attached file coregrind/m_debuglog.c.diff.

Some notes:
- Binary operations are counted under the type of their first argument.
The second argument is ignored.
- With the changes I made in the output, the regression test for Lackey
should fail, but does not, and I don't see why.

Jeroen.

>> >> - In the 'switch (st->tag)' statement, the 'case Ist_Exit:' adds a
>> deep
>> >> copy of the statement to bb; whereas the 'default:' adds the
>> statement
>> >> itself. Is there a rationale behind this difference?
>
> No .. me being over cautious.  I'm pretty sure you can simply copy
> the statements themselves; doing deep copies just makes the instrumenter
> run slower :-)
>
>> 190 in attached file lk_main.c), I had to change the format from %u to
>> %llu to get it to work properly.
>
> %llu is the correct format for ULong, yes.
>
> J
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>