labath added a comment. Ok, after a bit more digging, this is what I have found:
> Error ProcessGDBRemote::GetLoadedModuleList (LoadedModuleInfoList & list); > This packet is not usable **in it's current form** as it does not include the UUID of the module. As far as I can tell, it is intended to provide the information present in the dynamic linker's rendezvous structure, which is something that we retrieve using memory reads at the moment (POSIX-DYLD plugin has support for the packet, but lldb-server does not implement it). It would probably be possible to extend that packet to include the UUID, but that would not be competely trivial as it would require the reimplementation of a large part (the one that reads out the rendezvous structure) of the POSIX-DYLD plugin on the server side. This is something we may want to do eventually, as reading out of the rendezvous structure (it's a linked list) is also quite slow, but it is not the bottleneck at the moment. So I am a bit reluctant to tie these two things together, as this is a big win already. > jGetLoadedDynamicLibrariesInfos This looks like a mac-specific version of the previous packet. It does include the UUID, but it also includes some mac-specific fields I don't need. It also has the same issue that it would require the remote side to traverse the rendezvous structure to retrieve the list of libraries. Given the choice between these two packets, I'd go with extending the first one, as POSIX-DYLD plugin already has some support for the "libraries-svr4" packet. In a way, the packet I am introducing is not really comparable the these two packets. It queries the UUID based on file name, which is an operation which does not even require a running process, whereas the previous two packets deal with reading out the loaded modules from an existing process - it's basically a batch version of the qModuleInfo packet - it's only connection to the dynamic linker is that the dynamic linker knows the names of the modules we will query. (BTW, is the qModuleInfo packet used on darwin targets?) So, my proposal would be the following: keep this packet as-is (it contains no platform-specific info, so it can be used elsewhere in similar ways that qModuleInfo is), and if we do implement server-side rendezvous structure parsing, then we can remove this packet (assuming to new uses for it have been invented). What do you think? https://reviews.llvm.org/D24236 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
