[llvm-dev] RFC: libtrace

[Zachary Turner via llvm-dev]

Hi all,

We have been thinking internally about a lightweight llvm-based ptracer.
To address one question up front: the primary way in which this differs
from LLDB is that it targets a more narrow use case -- there is no
scripting support, no clang integration, no dynamic extensibility, no
support for running jitted code in the target, and no user interface.  We
have several use cases internally that call for varying levels of
functionality from such a utility, and being able to use as little as
possible of the library as is necessary for the given task is important for
the scale in which we wish to use it.

We are still in early discussions and planning, but I think this would be a
good addition to the LLVM upstream.  Since we’re approaching this as a set
of small isolated components, my thinking is to work on this completely
upstream, directly under the llvm project (as opposed to making a separate
subproject), but I’m open to discussion if anyone feels differently.

LLDB has solved a lot of the difficult problems needed for such a tool.  So
in the spirit of code reuse, we think it’s worth trying componentize LLDB
by sinking pieces into LLVM and rebasing LLDB as well as these smaller
tools on top of these components, so that smaller tools can reduce code
duplication and contribute to the overall health of the code base.  At the
same time we think that in doing so we can break things up into more
granular pieces, ultimately exposing a larger testing surface and enabling
us to create exhaustive tests, giving LLDB more fine grained testing of
important subsystems.

A good example of this would be LLDB’s DWARF parsing code, which is more
featureful than LLVM’s but has kind of evolved in parallel.  Sinking this
into LLVM would be one early target of such an effort, although over time
there would likely be more.

Anyone have any thoughts / strong opinions on this proposal, or where the
code should live?  Also, does anyone have any suggestions on things they’d
like to see come out of this? Whether it’s a specific new tool, new
functionality to an existing tool, an architectural or design change to
some existing tool or library, or something else entirely, all feedback and
ideas are welcome.

Thanks,

Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180626/5aa395d5/attachment.html>