This if fine. We will want to make these changes as a virtual call in
lldb_private::Process where we ask the process if it can help discover loaded
shared libraries. The dynamic loader plug-ins will need to be modified to take
advantage of this as they get an abstract "lldb_private::Process*" when they
are created. Then the dynamic loader plug-ins can ask the process if they can
supply the module loaded info, and take advantage of this if needed.
Maybe something like:
namespace lldb_private {
class Process {
...
virtual Error GetLoadedSharedLibraries(std::vector<LoadedModuleInfo>
&loaded_modules)
{
Error error;
loaded_modules.clear();
error.SetErrorString("unimplemented");
return error;
}
I don't believe qModuleInfo if the correct call to be using. I believe this is
a platform packet only that allows you to ask about what a remote file
contains. It answers with the info on each contained file that is contained
within a file and returns the architecture, file offset, and file size for each
different slice. Most files only have one item inside them, so they would
return info on that single file. This isn't designed to be tied to a process
nor is it designed to pass along any module load info for a specific process.
I would just use the qXfer:libraries:read command and implement this as a new
call in "lldb_private::Process *" that returns an error in the default
implementation, and the ProcessGDBRemote will have a override version of this
function that can give us the info we need.
Let me know if you need any help in making this happen.
Greg
> On Apr 24, 2015, at 7:06 AM, Aidan Dodds <[email protected]> wrote:
>
> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
