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