<p dir="ltr">Thanks, Saleem. </p>
<p dir="ltr">We ended up having a few more conversations about the triple and I have left it alone. Instead I have added a distribution_id (and soon a distribution version) which ArchSpec and qHostInfo optionally handle. Linux distributions will fill this in with results from lsb_release if present. Android later will return 'android' here with the dist version set to the android release.</p>
<p dir="ltr">I still don't understand the value of the vendor in the triple if it's never set (or nearly always pc) in the case of linux kernel systems as widely varied as Android and Ubuntu, but the distribution additions will work well enough for us and won't disturb the ecosystem. :-)</p>
<p dir="ltr">-Todd</p>
<div class="gmail_quote">On Jan 24, 2014 6:30 PM, "Saleem Abdulrasool" <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><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" target="_blank">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>
</blockquote></div>