[lldb-dev] update: lldb-gdbserver on x86_64 linux

[Todd Fiala]

Thanks, Saleem.

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.

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. :-)

-Todd
On Jan 24, 2014 6:30 PM, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote:

> On Wed, Jan 15, 2014 at 5:25 PM, Todd Fiala <tfiala at google.com> wrote:
>
>> Hi all,
>>
>> I'm finally getting some cycles to put on lldb-gdbserver for x86_64 linux.
>>
>> 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.
>>
>> 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.
>>
>> # In the stream below, lgs is an abbreviation for lldb-gdbserver.
>> # The log is from running a simple program that loops and never
>> # stops, using lldb-gdbserver on a linux x86_64 platform.
>>
>> # lgs receives an ack in response to (presumably) something not
>> # recorded in the log.
>> <   1> read packet: +
>>
>>
>> # lgs receives a request to disable ack mode. Since we're
>> # communicating over reliable TCP, this is accepted. This will
>> # eliminate the future '+/-' responses between lgs and lldb.
>> <  19> read packet: $QStartNoAckMode#b0
>> <   1> send packet: +
>> <   6> send packet: $OK#9a
>> <   1> read packet: +
>>
>>
>> # Query if lgs supports adding a thread suffix to g/G (read/write all
>> # general registers) and p/P (read/write specified general register).
>> <  26> read packet: $QThreadSuffixSupported#e4
>> # Here lgs says "No, I can't do that." Bad answer - needs to be
>> # implemented for efficiency. TODO: Implement.
>> <   4> send packet: $#00
>>
>>
>> # This message first appeared with this change list:
>> #
>> http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20120409/005460.html
>> # Documentation is missing.
>> <  27> read packet: $QListThreadsInStopReply#21
>> # Here lgs says "No, I can't do that." Bad answer. TODO: Implement and
>> document.
>> <   4> send packet: $#00
>>
>>
>> # lldb requests info about the remote machine
>> <  13> read packet: $qHostInfo#9b
>>
>> # lgs reports the system triple: "x86_64--linux-gnu", where arch is
>> # x86_64, vendor probably should say ubuntu (but is empty), and os
>> # probably should be linux (instead of linux-gnu, where the extra dash
>> # is potentially a parsing issue and I would avoid).
>>
>>
> 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.
>
> The triple is parsed as the following tuple (yes, a triple contains four
> parts, contrary to the name):
> <arch>-<vendor>-<os>-<environment>.
>
> 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).
>
> #
>> # TODO:
>> #
>> # 1. modify the triple to provide the distribution in vendor (e.g.
>> # ubuntu, fedora, etc. as reported by "Distributor ID:" on
>> # 'lsb_release -a', or via the DISTRIB_ID= line of /etc/os-release.
>> # Use 'android' for linux (e.g. arm-android-linux).
>> #
>> # 2. add a dist_version. Set to match the distribution version. For
>> # ubuntu, you'd get 12.04, 13.10, etc. android you'd get 4.2, 4.3,
>> # 4.4.2, etc. os_version is still fine to be kernel version.
>> #
>> # 3. fix qHostInfo docs to include os_version and hostname keys.
>>
>> < 218> send packet:
>>
>> $triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;cputype:16777223;cpusubtype:3;watchpoint_exceptions_received:after;endian:little;os_version:3.2.5;hostname:686f73742e6578616d706c652e636f6d;#b4
>>
>>
>> # lldb is asking whether vCont is supported, and if so, which vCont
>> # actions are supported.
>> <  10> read packet: $vCont?#49
>> # lgs responds that it doesn't support vCont at all. This is an error
>> # on multi-threaded platforms. TODO: add support for vCont.
>> <   4> send packet: $#00
>>
>>
>> # lldb asks an undocumented question. Looking at code now. Checks to
>> # see if vAttachOrWait is supported. This is a command that allows for
>> # attaching to a given process name, or waiting for it to start and
>> # then attaching.
>> <  27> read packet: $qVAttachOrWaitSupported#38
>>
>> # lgs replies that it doesn't support it. Bad answer. TODO: implement.
>>
>> <   4> send packet: $#00
>>
>>
>> # lldb asks for the thread id of the current thread.
>> <   6> read packet: $qC#b4
>> # lgs responds with thread id 0. This might be right.
>> <   7> send packet: $QC0#c4
>>
>>
>> # lldb asks for the process info of the current process.
>> <  16> read packet: $qProcessInfo#dc
>>
>> # lgs says "I know nothing." Bad answer. TODO: implement
>>
>> <   4> send packet: $#00
>>
>> 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.
>>  --
>> Todd Fiala
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140124/d23f4464/attachment.html>