Ping On Thu Jul 24 2014 at 3:30:24 PM Russell Harmon <[email protected]> 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 <[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
