<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jul 8, 2016 at 9:57 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 28, 2016 at 12:31 AM, Dean Michael Berris 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- What is the preferred way of controlling the behaviour of the runtime library for something like XRay? Do the sanitizers check/use environment variables or commandline-flags to control behaviour at runtime/init?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The sanitizers each use a different, single environment variable:</div><div><a href="https://github.com/google/sanitizers/wiki/SanitizerCommonFlags" target="_blank">https://github.com/google/sanitizers/wiki/SanitizerCommonFlags</a></div><div>IMO this works pretty well, and it supports multiple flags.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><div><br></div><div>Awesome, thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- We would like to be able to trigger the patching/unpatching routines at runtime in a portable manner. In Linux and other UNIX-like environments signals (SIGUSR1 and SIGUSR2) might be good candidates for signalling the tracing infrastructure to start/stop at user-controlled times (useful for long-running servers). Is there a preference for this, or are there alternatives in this space that might make better sense?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>No idea, maybe others have a better idea.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><div><br></div><div>I suspect the bare minimum here would be to expose a single function that could be invoked to enable or disable tracing. Then that could be called in many different ways according to the application or through some supported, configurable, with sane defaults for the platforms supported.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Currently we are using 'printf' for the logging, but could use a simple thread-local in-memory log that flushes to disk when full. Any other preferred ways of doing this?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Should XRay use libc? Are there re-entrancy issues that we should be worried about? Most sanitizer code avoids calling libc directly, and most functionality (printf) is implemented internally. Maybe you should link sanitizer_common and use that.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><div><br></div><div>I wondered about that, and I think avoiding libc as much as possible is a good thing to do.</div><div><br></div><div>I'll work with sanitizer_common and re-use stuff from there instead, thanks for the pointer. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Documentation for how to use/run XRay may need to live in a central location, but since the changes to the LLVM pieces are currently in three different places, are there suggestions for where the docs should live?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The sanitizer docs are kind of spread out, unfortunately. There's some in clang, some on the github wiki, and probably some in LLVM. Personally I think the documentation should be in clang in rst.</div></div></div></div></blockquote><div><br></div><div>I think following current practice is fine for consistency (i.e. document the many different parts in many different places) but then have some sort of high-level documentation to present the use-cases and user scenarios. I'm fine with the user-facing documentation to be in clang too (i.e. how to xray-enable your application/libraries, then how to configure, etc.).</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Would love to know what others think about this particular point, but will proceed to add documentation through clang in rst.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Cheers </span></div></div></div>