[llvm-dev] XRay: Demo on x86_64/Linux almost done; some questions.

[Reid Kleckner via llvm-dev]

On Tue, Jun 28, 2016 at 12:31 AM, Dean Michael Berris via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> - 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?
>

The sanitizers each use a different, single environment variable:
https://github.com/google/sanitizers/wiki/SanitizerCommonFlags
IMO this works pretty well, and it supports multiple flags.


> - 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?
>

No idea, maybe others have a better idea.


> - 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?
>

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.


> - 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?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160707/51100ae0/attachment.html>