<div dir="ltr">Great, thanks Greg!<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">You can probably move the PlatformDarwin::DebugProcess() function up into PlatformPOSIX if you need to.</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I'll certainly do that if it looks useful.<br></font><div><br></div><div>I basically want to get a light TDD workflow going for remote lldb work, and I figured I can use that to drive some of the work.</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 1:49 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe you will need the lldb-platform and lldb-gdbserver to be in the same directory and compiled for the remote system you plan to test on.<br>
<br>
For clarify "<a href="http://remote.foo.com" target="_blank">remote.foo.com</a>%" will indicate commands to be run on the remote system, and "<a href="http://host.foo.com" target="_blank">host.foo.com</a>%" will be commands for the host computer...<br>
<br>
<a href="http://remote.foo.com" target="_blank">remote.foo.com</a>% ./lldb-platform --listen 2000<br>
Listening for a connection on 2000...<br>
<br>
<br>
<a href="http://host.foo.com" target="_blank">host.foo.com</a>% cd trunk/test<br>
<a href="http://host.foo.com" target="_blank">host.foo.com</a>% ./dotest.py --arch=armv7 --platform-name=remote-ios --platform-url=connect://<a href="http://remote.foo.com:2000" target="_blank">remote.foo.com:2000</a> --platform-working-dir=/var/root/test --compiler=/path/to/compiler/for/armv7/clang<br>
<br>
<br>
<br>
Then things just run! Of course we don't have direct access to the phone via network, so we use a USB mix. So we run a program that forwards ports 2000-2010 on the remote system and it adds a port offset of 10000, so we tell the platform about the port offset and the port range it can use:<br>
<br>
<a href="http://remote.foo.com" target="_blank">remote.foo.com</a>% ./lldb-platform --listen 2000 --port-offset 10000 --min-gdbserver-port 2001 --max-gdbserver-port 2010<br>
<br>
<br>
Then we add 10000 to 2000 when connecting in the --platform-url option:<br>
<br>
<a href="http://host.foo.com" target="_blank">host.foo.com</a>% ./dotest.py --arch=armv7 --platform-name=remote-ios --platform-url=connect://<a href="http://remote.foo.com:12000" target="_blank">remote.foo.com:12000</a> --platform-working-dir=/var/root/test --compiler=/path/to/compiler/for/armv7/clang<br>
<br>
That is about it. Before you try running tests, you can test this manually:<br>
<br>
<a href="http://remote.foo.com" target="_blank">remote.foo.com</a>% ./lldb-platform --listen 2000<br>
Listening for a connection on 2000...<br>
<br>
<a href="http://host.foo.com" target="_blank">host.foo.com</a>% lldb<br>
(lldb) platform select remote-ios<br>
(lldb) platform connect connect://<a href="http://remote.foo.com:2000" target="_blank">remote.foo.com:2000</a><br>
(lldb) file a.out<br>
(lldb) run<br>
<br>
A few things I can think of that you will need to change:<br>
<br>
1 - GDBRemoteCommunication::StartDebugserverProcess() is currently trying to locate the "debugserver" binary. You will need to change the #define:<br>
<br>
#if defined(__APPLE__)<br>
#define DEBUGSERVER_BASENAME "debugserver"<br>
#else<br>
#define DEBUGSERVER_BASENAME "lldb-gdbserver"<br>
#endif<br>
<br>
2 - You will need to make sure the "remote-linux" is working ok. When you type "run" above, it will run Platform::DebugProcess(...) and you will want to follow that through. For darwin this does:<br>
<br>
lldb::ProcessSP<br>
PlatformDarwin::DebugProcess (ProcessLaunchInfo &launch_info,<br>
Debugger &debugger,<br>
Target *target, // Can be NULL, if NULL create a new target, else use existing one<br>
Listener &listener,<br>
Error &error)<br>
{<br>
ProcessSP process_sp;<br>
<br>
if (IsHost())<br>
{<br>
process_sp = Platform::DebugProcess (launch_info, debugger, target, listener, error);<br>
}<br>
else<br>
{<br>
if (m_remote_platform_sp)<br>
process_sp = m_remote_platform_sp->DebugProcess (launch_info, debugger, target, listener, error);<br>
else<br>
error.SetErrorString ("the platform is not currently connected");<br>
}<br>
return process_sp;<br>
<br>
}<br>
<br>
<br>
which then calls down into the PlatformRemoteGDBServer::DebugProcess() when it is connected. The "m_remote_platform_sp" is part of PlatformPOSIX, so you might want to make sure that PlatformLinux inherits from PlatformPOSIX. You can probably move the PlatformDarwin::DebugProcess() function up into PlatformPOSIX if you need to.<br>
<br>
Let me know when you get further!<br>
<br>
Greg<br>
<div><div class="h5"><br>
<br>
On Dec 4, 2013, at 1:11 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> Greg - recently you mentioned some of the newer lldb work would support running remote-side unit tests. Can you sketch out how you see that working? I want to set up a few tests as I get started on the lldb-gdbserver work to validate my progress as I go along.<br>
><br>
> Thanks!<br>
><br>
> Sincerely,<br>
> Todd Fiala<br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div>