(Sorry about the delay -- it has been a busy week!)
On Thu, Mar 17, 2011 at 10:22:41AM -0700, Greg Clayton wrote: > Jim Ingham would like to see us have debugserver re-use LLDB shared > library (LLDB.framework on darwin, lldb.so on linux), and then > debugserver would just use the native debugger plugin (ProcessMacOSX > for darwin, ProcessLinux on linux) and avoid doing any symbol queries. > We might need some sort of minimal mode within the LLDB to make sure > we don't have both lldb and debugserver loading too many symbols, > though with the way we have architected LLDB to only do lookups when > asked, I think it would work just fine without any modifications. I agree. Perhaps the ultimate aim should be to ensure that debugserver never does any symbol lookups at all (since the client will sometimes be the only one with access to the debug info). In the absolute worst case we could add an LLDB specific set of callbacks that the target (i.e. Process) can request over the remote protocol. We could model that programmatically using a new "Environment" class or similar passed as an argument to Process::CreateInstance that would do the right thing depending on if we are running locally under lldb or remotely under debugserver. > I might try out this approach to see if it works. If it does, this > means everyone should get remote debugging for free, and need only > implement a single local Process plug-in. The only other thing I can think of immediately is that we would also need a way to access the "target" file system state -- not just the process state. IOW, an interface that translates into Host I/O packets when doing remote debugging and native FS operations otherwise. For example, in the linux dynamic loader we use /proc/pid/auxv which is a kernel-provided array of values. We can pick them off the stack using Process memory reads and writes but it is so much easier to just parse the file contents. There are other examples of in-kernel trace and debugging hooks that are provided thru different virtual file system interfaces. Perhaps what we need here is a TargetIO class with a standard set of virtual methods for reading and writing files. The Process plugin could provide a factory method that yields a reference to an instance of TargetIO. The default behaviour would be to return a generic instance that just does local open/read/write calls. The gdb-remote process plugin would provide it's own specialization that provides an implementation based on Host I/O packets. Does any of the above sound sane/useful? If so I can start looking at that side of things. -- steve _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
