On Apr 2, 2014, at 3:08 PM, Todd Fiala <[email protected]> wrote: > 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?
Yes, it will return a valid load address. > 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? No it isn't. > 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). Yes > 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? This value should be a value that points you to where the loaded sections might exist in memory. If the dynamic loader for linux on a native system will always use "/proc/..." then you don't need to return a valid value. This is really a hint to the dynamic loader to tell it where it should start to look. On MacOSX, it is either the address of the "/usr/lib/dyld" mach header, or the address of a structure in dyld's data section. On a native system you can probably always rely on reading from /proc, so my guess is you can return LLDB_INVALID_ADDRESS. We will then teach llgs to read the dynamic load info from "/proc" and return it through the packets that your guy was working on. Greg _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
