<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 15, 2014 at 5:25 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I'm finally getting some cycles to put on lldb-gdbserver for x86_64 linux.</div>
<div><br></div><div>I created a dummy looping exe (never exits), ran lldb_gdbserver against it in a terminal on my (local) x86_64 Ubuntu 12.04, turned on all logging, and attached from the (local) x86_64 Ubuntu 12.04 with top of tree as of yesterday. My only diffs at the moment are enabling lldb-gdbserver to build under linux and x86_64, and commenting out an assert that doesn't seem to make sense that always hits when starting up lldb-gdbserver.</div>
<div><br></div><div>See below for the communication transcript when attaching from the (local) lldb via the gdb-remote command. It pretty much defines my next several steps in terms of just getting lldb-gdbserver up and running on linux x86_64. I include this since I recall a few people were thinking of getting lldb-gdbserver up and running, and I didn't want to duplicate any applicable work that may have been implemented already in other branches.</div>
<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font size="1"># In the stream below, lgs is an abbreviation for lldb-gdbserver.</font></div><div><font size="1"># The log is from running a simple program that loops and never</font></div>
<div><font size="1"># stops, using lldb-gdbserver on a linux x86_64 platform.</font></div><div><br></div><div><font size="1"># lgs receives an ack in response to (presumably) something not</font></div><div><font size="1"># recorded in the log.</font></div>
<div><font size="1">< 1> read packet: +</font></div><div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># lgs receives a request to disable ack mode. Since we're</font></div>
<div><font size="1"># communicating over reliable TCP, this is accepted. This will</font></div><div><font size="1"># eliminate the future '+/-' responses between lgs and lldb.</font></div><div><font size="1">< 19> read packet: $QStartNoAckMode#b0</font></div>
<div><font size="1">< 1> send packet: +</font></div><div><font size="1">< 6> send packet: $OK#9a</font></div><div><font size="1">< 1> read packet: +</font></div><div><font size="1"><br></font></div>
<div><font size="1"><br></font></div><div><font size="1"># Query if lgs supports adding a thread suffix to g/G (read/write all</font></div><div><font size="1"># general registers) and p/P (read/write specified general register).</font></div>
<div><font size="1">< 26> read packet: $QThreadSuffixSupported#e4</font></div><div><font size="1"># Here lgs says "No, I can't do that." Bad answer - needs to be</font></div><div><font size="1"># implemented for efficiency. TODO: Implement.</font></div>
<div><font size="1">< 4> send packet: $#00</font></div><div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># This message first appeared with this change list:</font></div>
<div><font size="1"># <a href="http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20120409/005460.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20120409/005460.html</a></font></div>
<div><font size="1"># Documentation is missing.</font></div>
<div><font size="1">< 27> read packet: $QListThreadsInStopReply#21</font></div><div><font size="1"># Here lgs says "No, I can't do that." Bad answer. TODO: Implement and document.</font></div><div><font size="1">< 4> send packet: $#00</font></div>
<div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># lldb requests info about the remote machine</font></div><div><font size="1">< 13> read packet: $qHostInfo#9b</font></div>
<div><font size="1"><br></font></div><div><font size="1"># lgs reports the system triple: "x86_64--linux-gnu", where arch is</font></div><div><font size="1"># x86_64, vendor probably should say ubuntu (but is empty), and os</font></div>
<div><font size="1"># probably should be linux (instead of linux-gnu, where the extra dash</font></div><div><font size="1"># is potentially a parsing issue and I would avoid).</font></div></blockquote></div></div></blockquote>
<div><br></div><div>I believe that the triple (which is actually a triple here!) is correct/acceptable. At the very least, within the context of LLVM's handling, the triple is valid (though, I believe that GNU tools will also handle it correctly). The "extra" dash is there for clarity.</div>
<div><br></div><div>The triple is parsed as the following tuple (yes, a triple contains four parts, contrary to the name):</div><div><arch>-<vendor>-<os>-<environment>.</div><div><br></div><div>As such, the triple is parsed as a x86_64 linux host with a GNU environment. IIRC, llvm::Triple will treat x86_64-linux-gnu as an equivalent triple (and will internally canonicalise it to x86_64--linux-gnu).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font size="1">#</font></div>
<div><font size="1"># TODO:</font></div><div><font size="1">#</font></div><div><font size="1"># 1. modify the triple to provide the distribution in vendor (e.g.</font></div><div><font size="1"># ubuntu, fedora, etc. as reported by "Distributor ID:" on</font></div>
<div><font size="1"># 'lsb_release -a', or via the DISTRIB_ID= line of /etc/os-release.</font></div><div><font size="1"># Use 'android' for linux (e.g. arm-android-linux).</font></div><div><font size="1">#</font></div>
<div><font size="1"># 2. add a dist_version. Set to match the distribution version. For</font></div><div><font size="1"># ubuntu, you'd get 12.04, 13.10, etc. android you'd get 4.2, 4.3,</font></div><div><font size="1"># 4.4.2, etc. os_version is still fine to be kernel version.</font></div>
<div><font size="1">#</font></div><div><font size="1"># 3. fix qHostInfo docs to include os_version and hostname keys.</font></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>
<font size="1">< 218> send packet:</font></div><div><font size="1">$triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;cputype:16777223;cpusubtype:3;watchpoint_exceptions_received:after;endian:little;os_version:3.2.5;hostname:686f73742e6578616d706c652e636f6d;#b4</font></div>
<div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># lldb is asking whether vCont is supported, and if so, which vCont</font></div><div><font size="1"># actions are supported.</font></div>
<div><font size="1">< 10> read packet: $vCont?#49</font></div><div><font size="1"># lgs responds that it doesn't support vCont at all. This is an error</font></div><div><font size="1"># on multi-threaded platforms. TODO: add support for vCont.</font></div>
<div><font size="1">< 4> send packet: $#00</font></div><div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># lldb asks an undocumented question. Looking at code now. Checks to</font></div>
<div><font size="1"># see if vAttachOrWait is supported. This is a command that allows for</font></div><div><font size="1"># attaching to a given process name, or waiting for it to start and</font></div><div><font size="1"># then attaching.</font></div>
<div><font size="1">< 27> read packet: $qVAttachOrWaitSupported#38</font></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font size="1"># lgs replies that it doesn't support it. Bad answer. TODO: implement.</font></div>
</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font size="1">< 4> send packet: $#00</font></div><div><font size="1"><br></font></div><div><font size="1"><br></font></div>
<div><font size="1"># lldb asks for the thread id of the current thread.</font></div><div><font size="1">< 6> read packet: $qC#b4</font></div><div><font size="1"># lgs responds with thread id 0. This might be right.</font></div>
<div><font size="1">< 7> send packet: $QC0#c4</font></div><div><font size="1"><br></font></div><div><font size="1"><br></font></div><div><font size="1"># lldb asks for the process info of the current process.</font></div>
<div><font size="1">< 16> read packet: $qProcessInfo#dc</font></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font size="1"># lgs says "I know nothing." Bad answer. TODO: implement</font></div>
</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font size="1">< 4> send packet: $#00</font></div></div><div><br></div></blockquote></div><div><div>I'll start digging into these. I'll flip on building of lldb-gdbserver for x86_64 as soon as I have it doing anything more than just the above.</div>
<span class="HOEnZb"><font color="#888888">
-- <br><div><font color="#555555" face="arial, sans-serif"><span style="white-space:nowrap">Todd Fiala</span></font><br><br></div>
</font></span></div></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>