[lldb-dev] Trying to understand Platform::IsHost

[Greg Clayton]

You should actually be using platform-linux and when it connects you would then connect it using a member variable that implements the lldb-platform. See PlatformPOSIX:


Error
PlatformPOSIX::ConnectRemote (Args& args)
{
    Error error;
    if (IsHost())
    {
        error.SetErrorStringWithFormat ("can't connect to the host platform '%s', always connected", GetPluginName().GetCString());
    }
    else
    {
        if (!m_remote_platform_sp)
            m_remote_platform_sp = Platform::Create (ConstString("remote-gdb-server"), error);



So you shouldn't be making a platform remote GDB server, you should make the linux one. Why? Because linux will have a different notion of what architectures are available, where to look for a local cache of the remote machines "remote-linux" has debugged already (where it might have copied /usr/bin/*.so and many other files already into a local cache), where to find locally built things, etc. 

For example, the iOS platform knows to check for shared libraries in the SDK inside /Applications/Xcode.app in case your device matches the exact SDK that is installed, otherwise it will find things in the user directory. Check this out:

(lldb) platform select remote-ios 
  Platform: remote-ios
 Connected: no
  SDK Path: "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.x (??????)"
 SDK Roots: [ 0] "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.x (?????)"
 SDK Roots: [ 1] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/7.0 (11A409)"
 SDK Roots: [ 2] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/8.0 (12A365)"
 SDK Roots: [ 3] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/8.1 (12B410)"
 SDK Roots: [ 4] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/8.1 (12B411)"
 SDK Roots: [ 5] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B435)"
 SDK Roots: [ 6] "/Volumes/work/gclayton/Library/Developer/Xcode/iOS DeviceSupport/8.1.2 (12B440)"


Some numbers above were changed to 'x' and ?????? since they are newer than what is released. 

So think of a platform as something that knows how to locate files for anything it might have remote debugged before. You might want to devise a location in the user's directory (like we do above for iOS) where you can cache shared libraries from the remote linux machine so that subsequent debugging of apps is lightning fast (download shared libraries once). So most of the smarts that you added to the GDB remote platform should probably go into the PlatformLinux and be removed from PlatformGDBRemote. Many calls in your linux platform that are done by the remote GDB platform become pass through function calls:

PlatformLinux:Foo()
{
    if (m_remote_platform_sp)
        m_remote_platform_sp->Foo();
}

They are all on the "use GDB remote to do most stuff via m_remote_platform_sp", and probably also might have implemented some of the calls.
> On Jan 20, 2015, at 4:46 PM, Vince Harron <vharron at google.com> wrote:
> 
> Hi all (Greg),
> 
> Thus far I've been using remote-gdb-server as my platform for remote debugging.  What is remote-linux for?  Is it deprecated and destined to be removed or ?
> 
> What about 
> 
> 	remote-freebsd
> 	remote-windows


They are all on the "use GDB remote to do most stuff via m_remote_platform_sp", and probably also might have implemented some of the platform calls. I don't think anyone is doing any intelligent caching of remote symbols, and this probably needs to be implemented. Feel free to build a lot of stuff up into the actual Platform.cpp so anyone can benefit. So if your PlatformLinux is asked to find "/usr/lib/libfoo.so", it should download and cache it locally in something like:

/path/to/user/lldb-platform/cache/linux/<host>/usr/lib/libfoo.so 

where <host> is the hostname of the remote linux machine. The first time you debug something, it might be really slow as files are downloaded across the GDB remote protocol, but then it can be fast. There are also rsync preferences that can be setup and the platforms can/should use to get the files even faster. There is some support for this built into some of the platform code somewhere, but it isn't tested and needs improvement.

Greg