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
Vince
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
Vince
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.