← Back to branch summary

~bkerensa/ubuntu/raring/valgrind/merge-from-deb

« back to all changes in this revision

Viewing changes to memcheck/docs/mc-tech-docs.xml

  • Committer: Bazaar Package Importer
  • Author(s): Andrés Roldán
  • Date: 2008-06-13 02:31:40 UTC
  • mto: (1.4.1 upstream) (2.2.1 squeeze)
  • mto: This revision was merged to the branch mainline in revision 24.
  • Revision ID: james.westby@ubuntu.com-20080613023140-iwk33rz9rhvfkr96
Import upstream version 3.3.1

Show diffs side-by-side

added added

removed removed

Lines of Context:
memcheck/docs/mc-tech-docs.xml
708
708
    do stores and loads of V bits to/from the sparse array which
709
709
    keeps track of V bits in memory, and
710
710
    <computeroutput>VGM_(handle_esp_assignment)</computeroutput>,
711
 
    which messes with memory addressibility resulting from
 
711
    which messes with memory addressability resulting from
712
712
    changes in <computeroutput>%ESP</computeroutput>.</para>
713
713
  </listitem>
714
714
 
1185
1185
  <listitem>
1186
1186
    <para><computeroutput>LEA1</computeroutput> and
1187
1187
    <computeroutput>LEA2</computeroutput> are not strictly
1188
 
    necessary, but allow faciliate better translations.  They
 
1188
    necessary, but facilitate better translations.  They
1189
1189
    record the fancy x86 addressing modes in a direct way, which
1190
1190
    allows those amodes to be emitted back into the final
1191
1191
    instruction stream more or less verbatim.</para>
1302
1302
    from the synthesised shadow memory that Valgrind maintains.
1303
1303
    In fact they do more than that, since they also do
1304
1304
    address-validity checks, and emit complaints if the
1305
 
    read/written addresses are unaddressible.</para>
 
1305
    read/written addresses are unaddressable.</para>
1306
1306
  </listitem>
1307
1307
 
1308
1308
  <listitem>
1716
1716
    because it is vital the instrumenter always has an up-to-date
1717
1717
    <computeroutput>%ESP</computeroutput> value available,
1718
1718
    <computeroutput>%ESP</computeroutput> changes affect
1719
 
    addressibility of the memory around the simulated stack
 
1719
    addressability of the memory around the simulated stack
1720
1720
    pointer.</para>
1721
1721
 
1722
1722
    <para>The implication of the above paragraph is that the
2594
2594
  VALGRIND_MAKE_READABLE(addr, len)]]></programlisting>
2595
2595
 
2596
2596
<para>and also, to check that memory is
2597
 
addressible/initialised,</para>
 
2597
addressable/initialised,</para>
2598
2598
<programlisting><![CDATA[
2599
 
  VALGRIND_CHECK_ADDRESSIBLE(addr, len)
 
2599
  VALGRIND_CHECK_ADDRESSABLE(addr, len)
2600
2600
  VALGRIND_CHECK_INITIALISED(addr, len)]]></programlisting>
2601
2601
 
2602
2602
<para>I then include in my sources a header defining these
2691
2691
    run it on post-CPP'd C/C++ source.  The parser/prettyprinter 
2692
2692
    is probably not as hard as it sounds; I would write it in Haskell, 
2693
2693
    a powerful functional language well suited to doing symbolic
2694
 
    computation, with which I am intimately familar.  There is
 
2694
    computation, with which I am intimately familiar.  There is
2695
2695
    already a C parser written in Haskell by someone in the
2696
2696
    Haskell community, and that would probably be a good starting
2697
2697
    point.</para>