<div dir="ltr">Hey Greg,<div><br></div><div>At the moment I'm working on implementing the NativeProcessProtocol::GetSharedLibraryInfoAddress () method for Linux.</div><div><br></div><div>From the docs:</div><div><br></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//----------------------------------------------------------------------<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">// "qShlibInfoAddr"<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">// BRIEF<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  Get an address where the dynamic linker stores information about <br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  where shared libraries are loaded.<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">// PRIORITY TO IMPLEMENT<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  High if you have a dynamic loader plug-in in LLDB for your target<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  triple (see the "qHostInfo" packet) that can use this information.<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  Many times address load randomization can make it hard to detect <br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  where the dynamic loader binary and data structures are located and<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  some platforms know, or can find out where this information is.<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  Low if you have a debug target where all object and symbol files <br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//  contain static load addresses.<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">//----------------------------------------------------------------------</span><font color="#000000" face="courier new, monospace" size="1"><span style="white-space:pre"><br>
</span></font><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to each<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">debugger as to where to find the dynamic loader information. For darwin<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">binaires that run in user land this is the address of the "all_image_infos"<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">stucture in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO<br>
</span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">call. The result is returned as big endian hex bytes that are the address<br></span><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">value:</span><font color="#000000" face="courier new, monospace" size="1"><span style="white-space:pre"><br>
</span></font><span style="font-family:'courier new',monospace;font-size:x-small;color:rgb(0,0,0)">send packet: $qShlibInfoAddr#00</span><div><pre style="color:rgb(0,0,0)"><font face="courier new, monospace" size="1">read packet: $7fff5fc40040#00</font></pre>
</div></blockquote><font color="#000000"><span style="white-space:pre"><div style="font-family:monospace"><font color="#000000" face="monospace"><span style="white-space:pre"><br></span></font></div><font face="arial, helvetica, sans-serif">I presume I will have the gdb remote qShlibInfoAddr handler in GDBRemoteCommunicationServer handle this by deferring to NativeProcessProtocol::GetSharedLibraryInfoAddress (), </font></span></font><div>
<font color="#000000" face="arial, helvetica, sans-serif"><span style="white-space:pre"><br></span></font></div><div><font color="#000000" face="arial, helvetica, sans-serif"><span style="white-space:pre">A few questions on this:</span></font></div>
<div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">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.</span></div>
<div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">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.  </span><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">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.  </span><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;white-space:pre">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.)</span></div>
<div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Thoughts here?</span></div>
<div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="white-space:pre;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Thanks!</span></div><div>
<div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">
Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px">
 <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34)">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px">
<font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div></div></div>