|
From: Mark W. <ma...@so...> - 2020-05-13 15:59:36
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8e40553f72ca5a95e25d412eec08bdd63045aa3b commit 8e40553f72ca5a95e25d412eec08bdd63045aa3b Author: Mark Wielaard <ma...@kl...> Date: Wed May 13 15:26:53 2020 +0200 hg-manual.xml: listitems contain paras, not CDATA. Diff: --- helgrind/docs/hg-manual.xml | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/helgrind/docs/hg-manual.xml b/helgrind/docs/hg-manual.xml index 8a1d9166aa..887a4be519 100644 --- a/helgrind/docs/hg-manual.xml +++ b/helgrind/docs/hg-manual.xml @@ -1178,25 +1178,29 @@ unlock(mx) unlock(mx) <para>The following aspects have to be considered when using <option>--delta-stacktrace=yes</option> : <itemizedlist> - <listitem>In some cases (for example in a function prologue), the - valgrind unwinder might not properly unwind the stack, due to some - limitations and/or due to wrong unwind info. When using - --delta-stacktrace=yes, the wrong stack trace captured in the - function prologue will be kept till the next call or return. - </listitem> - <listitem>On the other hand, --delta-stacktrace=yes sometimes helps to - obtain a correct stacktrace, for example when the unwind info allows - a correct stacktrace to be done in the beginning of the sequence, - but not later on in the instruction sequence.</listitem> - <listitem>Determining which instructions are changing the callstack is - partially based on platform dependent heuristics, which have to be - tuned/validated specifically for the platform. Also, unwinding in a - function prologue must be good enough to allow using - --delta-stacktrace=yes. Currently, the option --delta-stacktrace=yes - has been reasonably validated only on linux x86 32 bits and linux - amd64 64 bits. For more details about how to validate - --delta-stacktrace=yes, see debug option --hg-sanity-flags and the - function check_cached_rcec_ok in libhb_core.c.</listitem> + <listitem><para>In some cases (for example in a function + prologue), the valgrind unwinder might not properly unwind + the stack, due to some limitations and/or due to wrong + unwind info. When using --delta-stacktrace=yes, the wrong + stack trace captured in the function prologue will be kept + till the next call or return. + </para></listitem> + <listitem><para>On the other hand, --delta-stacktrace=yes + sometimes helps to obtain a correct stacktrace, for + example when the unwind info allows a correct stacktrace + to be done in the beginning of the sequence, but not later + on in the instruction sequence.</para></listitem> + <listitem><para>Determining which instructions are changing + the callstack is partially based on platform dependent + heuristics, which have to be tuned/validated specifically + for the platform. Also, unwinding in a function prologue + must be good enough to allow using + --delta-stacktrace=yes. Currently, the option + --delta-stacktrace=yes has been reasonably validated only + on linux x86 32 bits and linux amd64 64 bits. For more + details about how to validate --delta-stacktrace=yes, see + debug option --hg-sanity-flags and the function + check_cached_rcec_ok in libhb_core.c.</para></listitem> </itemizedlist> </para> </listitem> |