<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">My view: I'd much rather things were
done in trunk as per proposal. Makes progress more visible, any
issues caught earlier and I think contributions easier done.<br>
<br>
Colin<br>
<br>
On 04/12/2013 16:56, Todd Fiala wrote:<br>
</div>
<blockquote
cite="mid:CAFab17+TOeA7YyviTozszyXjDj0WX143YsZq8F__1v8tVNUBgw@mail.gmail.com"
type="cite">
<div dir="ltr">Going back through the initial proposal here:
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://www.mail-archive.com/lldb-dev@cs.uiuc.edu/msg02164.html">http://www.mail-archive.com/lldb-dev@cs.uiuc.edu/msg02164.html</a><br>
</div>
<div><br>
</div>
<div>I see the proposal was to do this work in trunk:</div>
<div><br>
</div>
<div>> <span
style="color:rgb(0,0,0);font-family:courier,'courier
new',monospace;font-size:14px;line-height:19.600000381469727px;white-space:pre-wrap">Since
the new classes can be implemented without impacting the
current </span><span
style="color:rgb(0,0,0);font-family:courier,'courier
new',monospace;font-size:14px;line-height:19.600000381469727px;white-space:pre-wrap">functionality,
we propose doing this work in trunk. Note that Greg's
platform </span><span
style="color:rgb(0,0,0);font-family:courier,'courier
new',monospace;font-size:14px;line-height:19.600000381469727px;white-space:pre-wrap">branch
was recently merged.</span></div>
<div><span style="color:rgb(0,0,0);font-family:courier,'courier
new',monospace;font-size:14px;line-height:19.600000381469727px;white-space:pre-wrap"><br>
</span></div>
<div>Assuming that is still valid, I could just work in trunk it
seems. Sound reasonable?</div>
<div><br>
</div>
<div>-Todd</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Dec 4, 2013 at 8:40 AM, Todd
Fiala <span dir="ltr"><<a moz-do-not-send="true"
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">I'm going to start working on getting
lldb-gdbserver working under Linux x86_64.
<div><br>
</div>
<div>
What's going to be the right submission workflow for
this? Should I plan on working in a separate branch
until I have something working, and then put up a large
patch? I'll be working in git locally. If we have
interim work at check points (but not generally useful
yet), does lldb use some kind of svn branching where it
might make sense to do checkpoint check-ins? That would
allow sharing progress outside of my local group here.</div>
<div><br>
</div>
<div>Thanks! </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div class="im">On Thu, Nov 21, 2013 at 10:49 AM, Greg
Clayton <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span>
wrote:<br>
</div>
<div>
<div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Todd,<br>
<br>
I went ahead and created a new "lldb-gdbserver"
tool in "trunk/tools/lldb-gdbserver" in the
repository.<br>
<br>
I also started the Host layer abstraction (see
include/Host/Debug.h) for processes
(NativeProcessProtocol) and threads
(NativeThreadProtocol).<br>
<br>
In order to get a lldb-gdbserver up and running,
it will be a matter of adding new packet support
to the GDBRemoteCommunicationServer class to
accept all of the standard GDB remote packets used
for debugging. The GDBRemoteCommunicationServer
class currently supports the lldb-platform
packets, but doesn't implement a lot of the normal
GDB remote packets.<br>
<br>
So the work flow to get this working on linux will
be:<br>
1 - Implement a linux version
NativeProcessProtocol and NativeThreadProtocol by
having them used the ProcessMonitor stuff that is
down in the linux native debugger plug-in.<br>
2 - Implement any needed GDB remote packets in
GDBRemoteCommunicationServer and back them by a
single instance of NativeProcessProtocol when
launching or attaching to a process.<br>
<br>
If you need any help let me know. I am sure there
is stuff missing from NativeProcessProtocol and
NativeThreadProtocol, so let me know if you need
anything else. Also please ask questions as you go
if you need any help.<br>
<span><font color="#888888"><br>
Greg Clayton<br>
</font></span>
<div>
<div><br>
<br>
On Nov 20, 2013, at 4:15 PM, Todd Fiala <<a
moz-do-not-send="true"
href="mailto:tfiala@google.com"
target="_blank">tfiala@google.com</a>>
wrote:<br>
<br>
> Perfect, thanks!<br>
><br>
> Technically I'll be using whatever the
Android NDK gdbserver is - I'll need to track
down what (if any) patches are applied to
that.<br>
><br>
><br>
> On Wed, Nov 20, 2013 at 3:56 PM, Greg
Clayton <<a moz-do-not-send="true"
href="mailto:gclayton@apple.com"
target="_blank">gclayton@apple.com</a>>
wrote:<br>
> If you are going to use a stock gdbserver
binary, you will need to make a target
definition python file. We have a few examples
checked in:<br>
><br>
> svn cat <a moz-do-not-send="true"
href="http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py"
target="_blank">http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py</a><br>
> svn cat <a moz-do-not-send="true"
href="http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py"
target="_blank">http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py</a><br>
><br>
> When debugging using GDB, you will first
need to see the exact registers that the
gdbserver supplies:<br>
><br>
> (gdb) maint print raw-registers<br>
><br>
> Then you will need to make a register
definition file based off of that and point
lldb to use it:<br>
><br>
> (lldb) settings set
plugin.process.gdb-remote.target-definition-file
/path/to/trunk/examples/python/x86_64_target_definition.py<br>
><br>
> Then LLDB will be able to debug to a
remote gdb server that doesn't support any of
the dynamic register definition packets.<br>
><br>
> Greg<br>
><br>
><br>
> On Nov 20, 2013, at 2:50 PM, Todd Fiala
<<a moz-do-not-send="true"
href="mailto:tfiala@google.com"
target="_blank">tfiala@google.com</a>>
wrote:<br>
><br>
> > Great, thanks Andy. Right now I'm
just at the point of using the stock
adb/gdbserver and see what that looks like.
I'll definitely be looking at your patch in a
bit here :-)<br>
> ><br>
> ><br>
> > On Wed, Nov 20, 2013 at 2:39 PM,
Kaylor, Andrew <<a moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"
target="_blank">andrew.kaylor@intel.com</a>>
wrote:<br>
> > Take a look at the patch I sent you.
It uses an lldb platform based on ADB to set
up the port forwarding and possibly copy files
then connects to gdbserver. The
implementation is rough, but the basic idea
seemed to work pretty well. I was using it to
copy over and launch a new version of
gdbserver because the one that came with the
x86 emulator at the time didn’t work.<br>
> ><br>
> ><br>
> ><br>
> > -Andy<br>
> ><br>
> ><br>
> ><br>
> > From: <a moz-do-not-send="true"
href="mailto:lldb-dev-bounces@cs.uiuc.edu"
target="_blank">lldb-dev-bounces@cs.uiuc.edu</a>
[mailto:<a moz-do-not-send="true"
href="mailto:lldb-dev-bounces@cs.uiuc.edu"
target="_blank">lldb-dev-bounces@cs.uiuc.edu</a>]
On Behalf Of Todd Fiala<br>
> > Sent: Wednesday, November 20, 2013
2:19 PM<br>
> > To: Greg Clayton<br>
> > Cc: lldb-dev<br>
> > Subject: Re: [lldb-dev] LLDB for
Android initiative<br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > > There is probably some amount
of overlap in lldb-platform and what we
currently do with adb (Android Debug Bridge).
Eventually I'll need to figure out what makes
sense to speed up the compile/deploy/debug/fix
cycle.<br>
> ><br>
> > You can make a new platform named
"remote-andriod" that can talk to adb, and
just skip using the "lldb-platform" binary.
Anything that is missing in that we need in
the lldb_private::Platform class could then be
added to adb, and if we are missing anything
in the lldb_private::Platform compared to adb
we could add to the platform API. How do you
communicate with adb? Sockets?<br>
> ><br>
> ><br>
> ><br>
> > ADB runs on the host/local side, and
it knows how to forward ports to devices
(typically over USB). So, we talk to the
local ADB port that then forwards
communication to the actual device. I'll need
to have a look at the guts of it - it might
make sense to only use it as a port forwarder
and go with an lldb-platform on the device
side and just stick with that. I'll have a
deeper look at that once I get Android
gdbserver (or equivalent) working.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> >
_______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:lldb-dev@cs.uiuc.edu"
target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> > <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Colin Riley
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Phone: +44 131 466 0503
Fax: +44 131 557 6600
Website: <a class="moz-txt-link-freetext" href="http://www.codeplay.com">http://www.codeplay.com</a>
Twitter: @codeplaysoft
This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY
</pre>
</body>
</html>