<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I've been working on implementing some basic functionality in order to<br>
use the llvm profiling functionality inside of a kernel (the Xen<br>
hypervisor). The only functionality I'm interested in is being able to<br>
reset the counters, get the size of the data, and dump the data into a<br>
memory buffer.<br>
<br>
I have to admit I haven't been able to find a lot of documentation<br>
about how this data is stored inside of the different sections, but<br>
with the code in compiler_rt/libs/profile I've been able to craft<br>
something that seems to do something sensible.<br>
<br>
I have however a couple of questions:<br>
<br>
- The "Values" field in __llvm_profile_data always seems to be NULL.<br>
Is this expected? What/why could cause this?<br></blockquote><div><br></div><div>This is for value profiling. For now there are only two kinds: indirect call targets and memcpy/memset size. If the function body does not have any value sites, the field will be null.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- The fields in the NumValueSites array inside of __llvm_profile_data<br>
also seem to always be 0.<br></blockquote><div><br></div><div>See above.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Since what I'm coding is a decoupled replacement for the profiling<br>
runtime inside of compiler_rt, is there anyway that at compile or<br>
run time I can fetch the version of the profiling data?<br></blockquote><div><br></div><div> At compile time, it is the macro: INST_PROF_RAW_VERSION. At runtime, it is the second field of the raw profile header.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm mostly worried that at some point llvm will bump the version<br>
and change the layout, and then I will have to update my runtime<br>
accordingly, but without llvm reporting the version used by the<br>
compiler it's going to be very hard to keep backwards<br>
compatibility or to detect version bumps.<br>
<br></blockquote><div><br></div><div>yes, the raw profile format can change anytime. We only try to keep backward compatibility for indexed format.</div><div><br></div><div>At runtime with in-process profile merging, if the source raw profile data's format version is different from the current runtime version, an error will be emitted.</div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks, Roger.<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>