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

[Saleem Abdulrasool]

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/d1bf8890/attachment.html>