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
> On Jun 26, 2018, at 2:00 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>> * unwinding and backtrace generation
>
> Jason says this will be somewhat tricky to pull out of lldb. OTOH much of
> the complexity of unwind is reconstructing all the non-volatile registers,
> and if you don't care ab
One important question, does this tool need to work remotely?
I'm guessing the answer to this is no, since if you are working remotely you
won't have a performant enough solution to really be an effective tracer. And
if the guts of the debugger are remote, you care a lot less about the
compl
Ahh, thanks. I thought those changes never landed, but it's good to hear
that they did.
On Tue, Jun 26, 2018 at 1:49 PM Adrian Prantl wrote:
>
> > On Jun 26, 2018, at 1:38 PM, Zachary Turner wrote:
> >
> >> On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl
> wrote:
> >>
> >>> > On Jun 26, 2018, a
> On Jun 26, 2018, at 1:38 PM, Zachary Turner wrote:
>
>> On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl wrote:
>>
>>> > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev
>>> > wrote:
>>> > A good example of this would be LLDB’s DWARF parsing code, which is more
>>> > featureful than
On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl wrote:
>
>
> > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > We have been thinking internally about a lightweight llvm-based
> ptracer. To address one question up front: the prim
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
> On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev
> wrote:
>
> 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 -- t
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
The BUILD_SHARED_LIBS part is likely to be the issue. LLDB libraries
have cyclic dependencies, which don't play well with shared libraries.
I think somebody "fixed" it some time ago (i.e., just made the flag be
ignored for lldb), but I'm not sure if he also checked the unit tests.
I'll see if I can
Hi Pavel,
I do an in-tree build, so lldb is next to clang.
And I use ccache, could that be a problem? If yes then why just with the
unit tests?
Here is how I configured cmake:
cmake ../../git/llvm -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=1
-DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER=clang++
-D
Hello Gabor,
The error message (Option 'help-list' registered more than once) leads
me to believe that this is caused by an uncommon (for lldb, at least)
build configuration. Can you share your cmake configuration?
I suspect TestLinuxCore is also failing due to unexpected build
configuration, spe
Hi
By using "ninja check-lldb-unit" some of the unit tests fail with the tip
of the master. (I am using Ubuntu Linux.) The error is always related to
the CommandLine options:
FAIL: lldb-Unit ::
ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences
(1
17 matches
Mail list logo
