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

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 7 16:57:17 PDT 2016

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

More information about the llvm-dev mailing list