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 <[email protected]> wrote: > On Mon Jul 14 2014 at 10:20:13 AM, Russell Harmon <[email protected]> > wrote: > >> On Fri Jul 11 2014 at 11:17:55 AM, Greg Clayton <[email protected]> >> 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. >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
