The major difference between the way lldb works now and what a simple tracer
library is going to want w.r.t. reporting events is that lldb currently assumes
either
(a)control gets returned to the user with the process stopped and they will
examine it at their leisure
(b) that the user restart
> On Jun 26, 2018, at 5:14 PM, Zachary Turner wrote:
>
> Yes that’s what I’ve been thinking about as well.
>
> One thing I’ve been giving a lot of thought to is whether to serialize the
> handling of trace events. I want to balance the “this is a library and you
> should be able to get it to
On Wed, 27 Jun 2018 at 14:11, Zachary Turner wrote:
>
> suppose process A (single threaded) is tracing process B (2 threads). If
> trace events happen on both threads of B, then the second thread can’t
> continue until both threads’ trace events have been fully handled,
> synchronously. If proc
suppose process A (single threaded) is tracing process B (2 threads). If
trace events happen on both threads of B, then the second thread can’t
continue until both threads’ trace events have been fully handled,
synchronously. If process A has a second thread though, the tracer thread
can enqueue wo
On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev
wrote:
>
> Yes that’s what I’ve been thinking about as well.
>
> One thing I’ve been giving a lot of thought to is whether to serialize the
> handling of trace events. I want to balance the “this is a library and you
> should be able to
Yes that’s what I’ve been thinking about as well.
One thing I’ve been giving a lot of thought to is whether to serialize the
handling of trace events. I want to balance the “this is a library and you
should be able to get it to work for you no matter what your use case is”
aspect with the “you re
The various NativeProcess implementations are definitely a good starting
point and I'll probably be looking at them to understand all the ins and
outs of each platform. I'm not sure if the API / interface we want will be
the same, so I don't think we can just copy it all down. But a lot of the
co
You'd probably need to pull the Unwinder in if you want backtraces, but that
part shouldn't be that hard to disentangle. I don't think you'd need much else?
Basing your work on NativeProcess rather than lldb proper would also cut the
number of observer processes in half and avoid the context sw
So you aren't planning to print values at all, just stop points (i.e. you are
only interested in the line table and function symbols part of DWARF)?
Given what you've described so far, I'm wondering if what you really want is
the NativeProcess classes with some symbol-file reading pulled in? Is
no expression parser or knowledge of any specific programming language.
Basically I just mean that the parsing of the native DWARF format itself is
in scope, but anything beyond that is out of scope. For symbolication we
have things like llvm-symbolizer that already just work and are built on
top
Just to be clear, by "no clang integration" do you mean "no expression parser"
or do you mean something more radical? For instance, adding a TypeSystem and
its DWARF parser for C family languages that uses a different underlying
representation than Clang AST's to store the results would be a lo
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
12 matches
Mail list logo
