[lldb-dev] Same-Process Debugging

[Russell Harmon]

Ping

On Thu Jul 24 2014 at 3:30:24 PM Russell Harmon <eatnumber1 at google.com>
wrote:

> Greg,
>
> I looked at Host, and I'm not sure it's the best place for these changes.
> There's quite a few methods there which will simply call into the already
> extant implementations for whatever host you're on. Of the functions that
> would need to behave differently when debugging yourself, take Backtrace
> for example, the logic of how to traverse the stack should be shared while
> the logic of how to read memory will differ.
>
> I think the model whereby lldb treats itself as just another process for
> most purposes makes sense, and using a NativeProcessProtocol implementation
> that inspects local memory etc. seems to make sense to me.
>
> Also, I'd made some responses to your other comments in my previous email.
> What do you think?
>
> Thanks,
> Russ Harmon
>
> On Mon Jul 14 2014 at 10:21:57 AM, Russell Harmon <eatnumber1 at google.com>
> wrote:
>
>> On Mon Jul 14 2014 at 10:20:13 AM, Russell Harmon <eatnumber1 at google.com>
>> wrote:
>>
>>> On Fri Jul 11 2014 at 11:17:55 AM, Greg Clayton <gclayton at apple.com>
>>> wrote:
>>>
>> >
>>>> > After talking with Todd Fiala, he suggested writing an implementation
>>>> of NativeProcessProtocol and NativeThreadProtocol that inspects the local
>>>> process. This would allow same-process debugging without the expensive IPC
>>>> that Ruminate has.
>>>>
>>>> What is the IPC needed for? Getting the backtraces? What exactly are
>>>> you looking to eliminate?
>>>>
>>>
>>> Well, for the ptrace() IPC, I have lldb stop the debugee for getting
>>> array members, function argument types, enum members and enumerating the
>>> members of an sbtype (struct members).
>>>
>>
>> Oh, and backtraces too.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140731/1a0332aa/attachment.html>