[lldb-dev] NativeProcessProtocol and GetSharedLibraryInfoAddress()

[Todd Fiala]

Hey Greg,

At the moment I'm working on implementing the
NativeProcessProtocol::GetSharedLibraryInfoAddress () method for Linux.

>From the docs:

//----------------------------------------------------------------------
// "qShlibInfoAddr"
//
// BRIEF
// Get an address where the dynamic linker stores information about
// where shared libraries are loaded.
//
// PRIORITY TO IMPLEMENT
// High if you have a dynamic loader plug-in in LLDB for your target
// triple (see the "qHostInfo" packet) that can use this information.
// Many times address load randomization can make it hard to detect
// where the dynamic loader binary and data structures are located and
// some platforms know, or can find out where this information is.
//
// Low if you have a debug target where all object and symbol files
// contain static load addresses.
//----------------------------------------------------------------------
LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to
each
debugger as to where to find the dynamic loader information. For darwin
binaires that run in user land this is the address of the "all_image_infos"
stucture in the "/usr/lib/dyld" executable, or the result of a
TASK_DYLD_INFO
call. The result is returned as big endian hex bytes that are the address
value:
send packet: $qShlibInfoAddr#00

read packet: $7fff5fc40040#00


I presume I will have the gdb remote qShlibInfoAddr handler in
GDBRemoteCommunicationServer handle this by deferring to
NativeProcessProtocol::GetSharedLibraryInfoAddress (),

A few questions on this:

Q: This needs to be a loaded address value, correct? Given the comments in
the priority section, it seems so, and much of the shared library info on
elf (rendezvous structures and such) is only available in memory form. Just
wanting to check my assumption because if it is wrong, the other question
is moot.

Q: Is it fair for NativeProcessProtocol to make use of the Target class? An
overall goal is to limit how much NativeProcesProtocol needs to touch,
which will help limit how much of lldb proper needs to be linked in on the
lldb-gdbserver side. In this case, I'm finding that load address
calculation (e.g. via ObjectFileELF::GetImageInfoAddress (Target *) )
ultimately need a Target to resolve a load address. I'm thinking the answer
would be no. I think we would want to avoid using Target within llgs
(lldb-gdbserver). If that's the case, I'll need to duplicate some of the
Section/SectionLoadList handling. When looking at the Target set of
functionality, it has a bunch of concepts that I'm thinking we don't want
to have to link in just to have the load address resolution (e.g.
broadcasters, execution contexts, heavy breakpoints, etc.)

Thoughts here?

Thanks!
-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140402/b2c7d7a0/attachment.html>