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.
Colin
On 04/12/2013 16:56, Todd Fiala wrote:
Going back through the initial proposal here:
http://www.mail-archive.com/[email protected]/msg02164.html
I see the proposal was to do this work in trunk:
> Since the new classes can be implemented without impacting the
current functionality, we propose doing this work in trunk. Note that
Greg's platform branch was recently merged.
Assuming that is still valid, I could just work in trunk it seems.
Sound reasonable?
-Todd
On Wed, Dec 4, 2013 at 8:40 AM, Todd Fiala <[email protected]
<mailto:[email protected]>> wrote:
I'm going to start working on getting lldb-gdbserver working under
Linux x86_64.
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.
Thanks!
On Thu, Nov 21, 2013 at 10:49 AM, Greg Clayton <[email protected]
<mailto:[email protected]>> wrote:
Todd,
I went ahead and created a new "lldb-gdbserver" tool in
"trunk/tools/lldb-gdbserver" in the repository.
I also started the Host layer abstraction (see
include/Host/Debug.h) for processes (NativeProcessProtocol)
and threads (NativeThreadProtocol).
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.
So the work flow to get this working on linux will be:
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.
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.
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.
Greg Clayton
On Nov 20, 2013, at 4:15 PM, Todd Fiala <[email protected]
<mailto:[email protected]>> wrote:
> Perfect, thanks!
>
> 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.
>
>
> On Wed, Nov 20, 2013 at 3:56 PM, Greg Clayton
<[email protected] <mailto:[email protected]>> wrote:
> 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:
>
> svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
> svn cat
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py
>
> When debugging using GDB, you will first need to see the
exact registers that the gdbserver supplies:
>
> (gdb) maint print raw-registers
>
> Then you will need to make a register definition file based
off of that and point lldb to use it:
>
> (lldb) settings set
plugin.process.gdb-remote.target-definition-file
/path/to/trunk/examples/python/x86_64_target_definition.py
>
> Then LLDB will be able to debug to a remote gdb server that
doesn't support any of the dynamic register definition packets.
>
> Greg
>
>
> On Nov 20, 2013, at 2:50 PM, Todd Fiala <[email protected]
<mailto:[email protected]>> wrote:
>
> > 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 :-)
> >
> >
> > On Wed, Nov 20, 2013 at 2:39 PM, Kaylor, Andrew
<[email protected] <mailto:[email protected]>> wrote:
> > 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.
> >
> >
> >
> > -Andy
> >
> >
> >
> > From: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Todd Fiala
> > Sent: Wednesday, November 20, 2013 2:19 PM
> > To: Greg Clayton
> > Cc: lldb-dev
> > Subject: Re: [lldb-dev] LLDB for Android initiative
> >
> >
> >
> > >
> > > 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.
> >
> > 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?
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
--
Colin Riley
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Phone: +44 131 466 0503
Fax: +44 131 557 6600
Website: http://www.codeplay.com
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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
