Remote side lldb unit tests

Hi all,

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.

Thanks!

Sincerely,
Todd Fiala

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.

For clarify "remote.foo.com%" will indicate commands to be run on the remote system, and "host.foo.com%" will be commands for the host computer...

remote.foo.com% ./lldb-platform --listen 2000
Listening for a connection on 2000...

host.foo.com% cd trunk/test
host.foo.com% ./dotest.py --arch=armv7 --platform-name=remote-ios --platform-url=connect://remote.foo.com:2000 --platform-working-dir=/var/root/test --compiler=/path/to/compiler/for/armv7/clang

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:

remote.foo.com% ./lldb-platform --listen 2000 --port-offset 10000 --min-gdbserver-port 2001 --max-gdbserver-port 2010

Then we add 10000 to 2000 when connecting in the --platform-url option:

host.foo.com% ./dotest.py --arch=armv7 --platform-name=remote-ios --platform-url=connect://remote.foo.com:12000 --platform-working-dir=/var/root/test --compiler=/path/to/compiler/for/armv7/clang

That is about it. Before you try running tests, you can test this manually:

remote.foo.com% ./lldb-platform --listen 2000
Listening for a connection on 2000...

host.foo.com% lldb
(lldb) platform select remote-ios
(lldb) platform connect connect://remote.foo.com:2000
(lldb) file a.out
(lldb) run

A few things I can think of that you will need to change:

1 - GDBRemoteCommunication::StartDebugserverProcess() is currently trying to locate the "debugserver" binary. You will need to change the #define:

#if defined(__APPLE__)
#define DEBUGSERVER_BASENAME "debugserver"
#else
#define DEBUGSERVER_BASENAME "lldb-gdbserver"
#endif

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:

lldb::ProcessSP
PlatformDarwin::DebugProcess (ProcessLaunchInfo &launch_info,
                              Debugger &debugger,
                              Target *target, // Can be NULL, if NULL create a new target, else use existing one
                              Listener &listener,
                              Error &error)
{
    ProcessSP process_sp;
    
    if (IsHost())
    {
        process_sp = Platform::DebugProcess (launch_info, debugger, target, listener, error);
    }
    else
    {
        if (m_remote_platform_sp)
            process_sp = m_remote_platform_sp->DebugProcess (launch_info, debugger, target, listener, error);
        else
            error.SetErrorString ("the platform is not currently connected");
    }
    return process_sp;
    
}

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.

Let me know when you get further!

Greg

Great, thanks Greg!

You can probably move the PlatformDarwin::DebugProcess() function up into PlatformPOSIX if you need to.

I’ll certainly do that if it looks useful.

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.