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 <[email protected]> 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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
