[lldb-dev] Same-Process Debugging

[Russell Harmon]

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/20140724/59b43594/attachment.html>