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

Todd Fiala tfiala at google.com
Wed Jan 15 17:25:08 PST 2014

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:
# Documentation is missing.
<  27> read packet: $QListThreadsInStopReply#21
# Here lgs says "No, I can't do that." Bad answer. TODO: Implement and
<   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).
# 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:

# 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140115/dcb04e75/attachment.html>

More information about the lldb-dev mailing list