Hi,
I would like to improve support for the case where LLDB is debugging a
remote target (via gdbserver)
yet doesn't have access to the target executable, and only has access to
a shared object already
loaded by the target.
This is supported from GDB, as I can connect to a remote GDBServer
without specifying any executable,
and after issuing 'set solib-search-paths' it will resolve all of the
loaded shared objects correctly, while
still being blind to the target executable.
I feel like LLDB should be able to connect to a remote target, and then
after issuing a 'target modules add'
command be able to resolve its load address automatically. I believe
LLDB can already do this to some extent
via the 'qModuleInfo' RSP packet.
The 'qXfer:libraries:read' packet is provided by GDBServer, and will
return an XML document containing
all of the shared objects loaded by the target and their load
addresses. It is possible to parse this now using the
recent libxml2 support in LLDB.
GDBRemoteCommunicationClient::GetModuleInfo() could be extended to try
and gain information about a
loaded module via the 'qXfer:libraries:read' packet if 'qModuleInfo'
fails or is not supported.
I would be interested to hear what others think, or get some feedback if
I have perhaps misunderstood something.
Thanks,
Aidan Dodds
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
