Remote debugging with lldb

Subprojects LLDB
1

Hi,

I’m trying to do remote debugging with lldb, but I keep running into problems.

How should I do it?

I tried running “debugserver localhost:42000” and then, on the lldb client:

platform select (remote-macosx | remote-gdb-server?) + platform connect?
platform select … + process connect?

Should I have the executable on both machines? Do I just need it on the lldb machine and lldb sends it to the server? Do I just need it on the server?

That’s good for the most basic case: client and server on Mac OS X.

Now, what about some different combinations?
debugserver on macosx + client on linux?
debugserver on Linux + client on macosx?
gdbserver on “any” machine + client on macosx? Which programs would be supported?

I would suppose you need the plugins for the combinations you want to use, but with the gdb-remote stuff, I’m getting confused.

In lldb_private::Initialize(), we initialize several plugins, depending on the operating system. I’m supposing the DynamicLoader and Process plugins (along with some others) are only needed when running as host, otherwise, we couldn’t, on Linux, debug a FreeBSD or Mac OS X target (since their initialization gets ifdeffed out).

I saw that, on Mac OS X, lldb spawns a debugserver that runs the program and they communicate using the plugin ProcessGDBRemote (another question: Why is that plug-in only started on Mac OS X? It has to run on the host, but otherwise I didn’t see much platform-specific stuff (I just skimmed the file)). Shouldn’t that Process plugin be also used with a PlatformRemoteGDBServer?

Thanks, in advance, for the reply,nbsp; Filipe

2

Hi,

I'm trying to do remote debugging with lldb, but I keep running into problems.

How should I do it?

I tried running "debugserver localhost:42000" and then, on the lldb client:

platform select (remote-macosx | remote-gdb-server?) + platform connect?
platform select … + process connect?

The platform stuff is still a work in progress which we hope to really perfect over the next year. If you are doing Mac to Mac debugging the best thing to do right now is:

AFP mount the root drive on the other machine. For these examples lets suppose we have machine1 and machine2. So the flow would be:

- machine1: start debugserver:
machine1 % debugserver localhost:12345 /bin/ls

- machine2: mount the root drive from machine2 and launch lldb:
machine2 % ./lldb
(lldb) platform select remote-macosx --sysroot /Volumes/machine1
(lldb) process connect connect://machine1:12345

This should do it. Currently the platforms don't do any file copying from one to the other, so you will need a copy of all executables and shared libraries to exist within the "Volumes/machine1" directory. So if you are running "/bin/ls" it should be available through your mount at: "/Volumes/machine1/bin/ls". Likewise for all shared libraries.

Should I have the executable on both machines? Do I just need it on the lldb machine and lldb sends it to the server? Do I just need it on the server?

Again, the platforms should eventually support "install" and "copy" for files, but they currently don't.

That's good for the most basic case: client and server on Mac OS X.

Now, what about some different combinations?
debugserver on macosx + client on linux?
debugserver on Linux + client on macosx?
gdbserver on "any" machine + client on macosx? Which programs would be supported?

Any of the above as long as you can mount the root drive and any other things you need within one directory as mentioned above.

I would suppose you need the plugins for the combinations you want to use, but with the gdb-remote stuff, I'm getting confused.

In lldb_private::Initialize(), we initialize several plugins, depending on the operating system. I'm supposing the DynamicLoader and Process plugins (along with some others) are only needed when running as host, otherwise, we couldn't, on Linux, debug a FreeBSD or Mac OS X target (since their initialization gets ifdeffed out).

None of these should really be ifdefed out, they should be being compiled on all platforms, excluding any "native only" plug-ins.

I saw that, on Mac OS X, lldb spawns a debugserver that runs the program and they communicate using the plugin ProcessGDBRemote (another question: Why is that plug-in only started on Mac OS X? It has to run on the host, but otherwise I didn't see much platform-specific stuff (I just skimmed the file)). Shouldn't that Process plugin be also used with a PlatformRemoteGDBServer?

The platform (currently on MacOSX built as the "lldb-platform" executable) can currently do the job of being launched on a remote host and it can spawn a new debugserver in order to debug a process on the host, list processes, attach to existing process and do much more. All the code that the "lldb-platform" uses if from the "lldb_private::Host" API layer, so it completely reuses the host code that can launch processes for debugging, and much more.

The ideal platform looking forward would:
- be a binary that runs natively on the remote machine that hopefully can be automatically launched when the remote host is contacted on a port. On MacOSX, we can add a launchd plist entry that would automatically launch "lldb-platform" (or any equivalent) when the remote host is contacted on a fixed port number.
- upload and download files from the platform and cache them locally (currently we require all files to be there already in the "--sysroot" for the platform)
- list and query info for existing processes (lldb-platform can already do this)
- launch a process whose executable exists on the remote host (possibly just updloaded via the platform) with any args required. This would spawn the process under a debugserver and return the port needed to connect.
- attach to an existing process (spawn a debugserver that will attach, an return the port number across the platform protocol)

So much of this works right now. You can try out the "lldb-platform" binary with the current build and pretend to debug remotely:

% ./lldb-platform --listen 1444
Listening for a connection on 1444...

Then launch lldb and connect:

% ./lldb
(lldb) platform select remote-macosx
  Platform: remote-macosx
Connected: no
(lldb) platform connect connect://localhost:1444
  Platform: remote-macosx
    Triple: x86_64-apple-darwin
OS Version: 10.7.1
    Kernel: Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64
  Hostname: myhost.apple.com
Connected: yes
(lldb) platform process list
40 matching processes were found on "myhost.apple.com"
PID PARENT USER ARCH NAME
====== ====== ========== ======= ============================
46384 46139 gclayton x86_64 lldb
.....
(lldb)

There is much work to do, but there is a lot of support already in place to get remote debugging started.

Let me know if you have any questions.

Greg Clayton

3

Hi,

Thanks for your reply. It’s nice to know that I was on the right path :slight_smile:

But I still have some questions:

Hi,

I’m trying to do remote debugging with lldb, but I keep running into problems.

How should I do it?

I tried running “debugserver localhost:42000” and then, on the lldb client:

platform select (remote-macosx | remote-gdb-server?) + platform connect?
platform select … + process connect?

The platform stuff is still a work in progress which we hope to really perfect over the next year. If you are doing Mac to Mac debugging the best thing to do right now is:

AFP mount the root drive on the other machine. For these examples lets suppose we have machine1 and machine2. So the flow would be:

  • machine1: start debugserver:
    machine1 % debugserver localhost:12345 /bin/ls

  • machine2: mount the root drive from machine2 and launch lldb:
    machine2 % ./lldb
    (lldb) platform select remote-macosx --sysroot /Volumes/machine1
    (lldb) process connect connect://machine1:12345

This should do it. Currently the platforms don’t do any file copying from one to the other, so you will need a copy of all executables and shared libraries to exist within the “Volumes/machine1” directory. So if you are running “/bin/ls” it should be available through your mount at: “/Volumes/machine1/bin/ls”. Likewise for all shared libraries.

Is the remote-macosx platform the one to choose in order to have more information about the program? Or could I also choose the remote-gdb-server platform (which seems more generic)? Is there some code that “isn’t there yet” on the remote-gdb-server?

I managed to run the program with both, but where is the difference between them? Or is it the same because you’ve wired the macosx-host platform to just start a remote-gdb-server?

I would suppose you need the plugins for the combinations you want to use, but with the gdb-remote stuff, I’m getting confused.

In lldb_private::Initialize(), we initialize several plugins, depending on the operating system. I’m supposing the DynamicLoader and Process plugins (along with some others) are only needed when running as host, otherwise, we couldn’t, on Linux, debug a FreeBSD or Mac OS X target (since their initialization gets ifdeffed out).

None of these should really be ifdefed out, they should be being compiled on all platforms, excluding any “native only” plug-ins.

So, in the future, lldb.cpp will simply run all that code, except for some of the Platform (and Process?) plugins? I’m supposing it’s most of them, since many depend on the debuggee, and not the platform where lldb is running (just the remote server).

I saw that, on Mac OS X, lldb spawns a debugserver that runs the program and they communicate using the plugin ProcessGDBRemote (another question: Why is that plug-in only started on Mac OS X? It has to run on the host, but otherwise I didn’t see much platform-specific stuff (I just skimmed the file)). Shouldn’t that Process plugin be also used with a PlatformRemoteGDBServer?

The platform (currently on MacOSX built as the “lldb-platform” executable) can currently do the job of being launched on a remote host and it can spawn a new debugserver in order to debug a process on the host, list processes, attach to existing process and do much more. All the code that the “lldb-platform” uses if from the “lldb_private::Host” API layer, so it completely reuses the host code that can launch processes for debugging, and much more.

The ideal platform looking forward would:

  • be a binary that runs natively on the remote machine that hopefully can be automatically launched when the remote host is contacted on a port. On MacOSX, we can add a launchd plist entry that would automatically launch “lldb-platform” (or any equivalent) when the remote host is contacted on a fixed port number.
  • upload and download files from the platform and cache them locally (currently we require all files to be there already in the “–sysroot” for the platform)
  • list and query info for existing processes (lldb-platform can already do this)
  • launch a process whose executable exists on the remote host (possibly just updloaded via the platform) with any args required. This would spawn the process under a debugserver and return the port needed to connect.
  • attach to an existing process (spawn a debugserver that will attach, an return the port number across the platform protocol)

So much of this works right now. You can try out the “lldb-platform” binary with the current build and pretend to debug remotely:

% ./lldb-platform --listen 1444
Listening for a connection on 1444…

Then launch lldb and connect:

% ./lldb
(lldb) platform select remote-macosx
Platform: remote-macosx
Connected: no
(lldb) platform connect connect://localhost:1444
Platform: remote-macosx
Triple: x86_64-apple-darwin
OS Version: 10.7.1
Kernel: Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64
Hostname: myhost.apple.com
Connected: yes
(lldb) platform process list
40 matching processes were found on “myhost.apple.com”
PID PARENT USER ARCH NAME
====== ====== ========== ======= ============================
46384 46139 gclayton x86_64 lldb
…
(lldb)

There is much work to do, but there is a lot of support already in place to get remote debugging started.

Let me know if you have any questions.

Greg Clayton

I’ll check some stuff with Linux and gdbserver and may have some more questions afterwards. I managed to do some “remote” debugging with lldb, with your help, which is one step closer to what I wanted.

Thanks,

Filipe

4

Is the remote-macosx platform the one to choose in order to have more information about the program? Or could I also choose the remote-gdb-server platform (which seems more generic)? Is there some code that "isn't there yet" on the remote-gdb-server?

If you are debugging a remote macosx machine, then use "remote-macosx". If it is anything else, then select "remote-gdb-server". Why? Becuase the platform for "remote-macosx" does know how to do "MacOSX" type things like how to resolve a bundle executable in case you say:

(lldb) file /Volumes/machine1/Applications/TextEdit.app

If you use the "remote-gdb-server" it won't know any of the macosx specifics.

I managed to run the program with both, but where is the difference between them?

See above and go look at the functions that are available in the Platform.h file to see what the platform does different for MacOSX.

Or is it the same because you've wired the macosx-host platform to just start a remote-gdb-server?

"remote-macosx" uses the GDB server platform since that is how we chose to implement it, though if a remote platform decided to implement all of the new LLDB platform GDB server packets, the debug session could do something totally different depending on what you attached to.

>
> I would suppose you need the plugins for the combinations you want to use, but with the gdb-remote stuff, I'm getting confused.
>
> In lldb_private::Initialize(), we initialize several plugins, depending on the operating system. I'm supposing the DynamicLoader and Process plugins (along with some others) are only needed when running as host, otherwise, we couldn't, on Linux, debug a FreeBSD or Mac OS X target (since their initialization gets ifdeffed out).
>

None of these should really be ifdefed out, they should be being compiled on all platforms, excluding any "native only" plug-ins.

So, in the future, lldb.cpp will simply run all that code, except for some of the Platform (and Process?) plugins?

Only the ones that do native debugging like the linux plug-in. So now linux debugging will behave very differently if it is locally debugged, versus remotely since LLDB has a native linux plug-in that will only compile and run on linux. On MacOSX, we always use debugserver, so this decouples us from having this issue.

I'm supposing it's most of them, since many depend on the debuggee, and not the platform where lldb is running (just the remote server).

Any plug-in that can support remote debugging should be compiled in, and should try to not include native header files that are only on the remote system.

I'll check some stuff with Linux and gdbserver and may have some more questions afterwards. I managed to do some "remote" debugging with lldb, with your help, which is one step closer to what I wanted.

If you launch a GDB on linux and type:

(gdb) maintenance print raw-registers

It will give you a good idea of what registers are expected and you could make LLDB have a hard coded set of registers for "i386-pc-linux" (or whatever the linux target triple is) and then just run the native Linux GDB server. Or write a new GDB server on linux that uses the code from the ProcessLinux.cpp.

Greg

5

Hi,

Some more questions. When does the ‘m_remote_platform_sp’ member in PlatformDarwin get assigned? It seems to me that the SP’s contents will always be NULL and the remote-macosx platform will never resolve an executable (in PlatformDarwin::ResolveExecutable). Shouldn’t the remote part of the platform, when m_remote_platform_sp is NULL, resolve the executable using the --sysroot option?

Regards,

Filipe

6

PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.

7

Hi,

PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.

Yes, but the other two platforms never assign to m_remote_platform_sp. Only PlatformDarwin::ConnectRemote() does. And this won’t get called when issuing a ‘platform select’ + ‘process connect’.

Hi,

I’m trying to do remote debugging with lldb, but I keep running into problems.

How should I do it?

I tried running “debugserver localhost:42000” and then, on the lldb client:

platform select (remote-macosx | remote-gdb-server?) + platform connect?
platform select … + process connect?

The platform stuff is still a work in progress which we hope to really perfect over the next year. If you are doing Mac to Mac debugging the best thing to do right now is:

AFP mount the root drive on the other machine. For these examples lets suppose we have machine1 and machine2. So the flow would be:

  • machine1: start debugserver:
    machine1 % debugserver localhost:12345 /bin/ls

  • machine2: mount the root drive from machine2 and launch lldb:
    machine2 % ./lldb
    (lldb) platform select remote-macosx --sysroot /Volumes/machine1
    (lldb) process connect connect://machine1:12345

This should do it. Currently the platforms don’t do any file copying from one to the other, so you will need a copy of all executables and shared libraries to exist within the “Volumes/machine1” directory. So if you are running “/bin/ls” it should be available through your mount at: “/Volumes/machine1/bin/ls”. Likewise for all shared libraries.

The problem is: what can you do? In my testing I couldn’t (with platform remote-macosx and sysroot=/) find out anything about the program. I could only do a process continue, and not much more. I couldn’t set breakpoints, I couldn’t see the source, etc. Is this simply not in place?

My problem with adding this is that AFAICT, I can’t know the remote system path for the file currently being debugged, using the gdb remote protocol (if I could, the process could set the correct target when connecting to the debugserver). target create also doesn’t allow me to say which program is being debugged because it wants a connected platform. target modules add will load information about the module, but not allow me to set breakpoints. Since we don’t have a target, the MacOSX DYLD plugin won’t get called when additional modules are loaded.

Since MacOSX is using the remote plugin for all debugging purposes it seems we only need to allow the MacOSX plugins to be used when using platform remote-macosx, as well as resolving the remote paths whenever asked. Is this right?

So, should we somehow get the path to the executable from the debugserver? Should we allow the user to do a target create … and use that file? Should ‘process connect’ receive an additional argument for the executable?

Regards,

Filipe

8

Hi,

PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.

Yes, but the other two platforms never assign to m_remote_platform_sp. Only PlatformDarwin::ConnectRemote() does. And this won’t get called when issuing a ‘platform select’ + ‘process connect’.

Correct. “process connect” connects you to a debugserver that is already debugging, or will debug a single process. The “platform connect” connects you to a platform which can then spawn new debugserver instances and let you connect to them.

9

Hi,

Hi,

PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.

Yes, but the other two platforms never assign to m_remote_platform_sp. Only PlatformDarwin::ConnectRemote() does. And this won’t get called when issuing a ‘platform select’ + ‘process connect’.

Correct. “process connect” connects you to a debugserver that is already debugging, or will debug a single process. The “platform connect” connects you to a platform which can then spawn new debugserver instances and let you connect to them.

Ok, I managed to do that and connect to a platform that spawns debugservers. That way, if I’m just in lldb-land and use the platform, everything is ok.

The problem is: imagine I have a gdbserver (let’s use debugserver as an example, which implements that part of the communication), but not an lldb-platform.
I should be able to select a platform and ‘process connect’ to that debugserver. The problem is that the executable modules won’t get set (and I can’t find a way to set them). That way, the DYLD plugin won’t get loaded (in Process::CompleteAttach), and I won’t be able to see any symbols nor set breakpoints symbolically. In short, I would be debugging assembly with no symbols (fun :slight_smile: ). ‘image add’ won’t help either (it will say it can break on some symbols, but won’t stop when it gets there.

One way to fix this is to allow ‘target create’ (or another command) to tell the debugger which executable file we’re using. That way, we could make it the executable image and then call CompleteAttach (or redo some of the steps) in order to get everything working (including the DYLD plugin). Is this a good way to do that? Or do you prefer to just have lldb talk to itself (and lldb-platform)?

One more question (from the last email) about another way we could do this:

10

Hi,

Hi,

PlatformDarwin is a base class and cant be instantiated on its own. PlatformMacOSX and PlatformRemoteiOS inherit from this base class and customize it.

Yes, but the other two platforms never assign to m_remote_platform_sp. Only PlatformDarwin::ConnectRemote() does. And this won't get called when issuing a 'platform select' + 'process connect'.

Correct. "process connect" connects you to a debugserver that is already debugging, or will debug a single process. The "platform connect" connects you to a platform which can then spawn new debugserver instances and let you connect to them.

Ok, I managed to do that and connect to a platform that spawns debugservers. That way, if I'm just in lldb-land and use the platform, everything is ok.

The problem is: imagine I have a gdbserver (let's use debugserver as an example, which implements that part of the communication), but not an lldb-platform.
I should be able to select a platform and 'process connect' to that debugserver. The problem is that the executable modules won't get set (and I can't find a way to set them). That way, the DYLD plugin won't get loaded (in Process::CompleteAttach), and I won't be able to see any symbols nor set breakpoints symbolically. In short, I would be debugging assembly with no symbols (fun :slight_smile: ). 'image add' won't help either (it will say it can break on some symbols, but won't stop when it gets there.

One way to fix this is to allow 'target create' (or another command) to tell the debugger which executable file we're using. That way, we could make it the executable image and then call CompleteAttach (or redo some of the steps) in order to get everything working (including the DYLD plugin). Is this a good way to do that? Or do you prefer to just have lldb talk to itself (and lldb-platform)?

Exactly! You should be able to specify the local copy of the file you have. We will always check the UUIDs of the executable files you have loaded when dyld comes along. For instance, locally you have a binary "/tmp/a.out". Remotely this file is in "/usr/local/bin/a.out".

You can start lldb, set the platform, set the file and attach:

% lldb
(lldb) platform select ...
(lldb) target create /tmp/a.out
(lldb) process connect ....

Now when the dynamic loader plug-in gets info about a remote binary, it will say the path is at "/usr/local/bin/a.out", but we will notice that the UUID in the binary matches, so we don't care what the local path is.

LLDB currently really needs to have local copies of the files in order to debug. The architecture you select when you create the target really helps to specify which sets of plug-ins get loaded.

One more question (from the last email) about another way we could do this:

> Hi,
>
> I'm trying to do remote debugging with lldb, but I keep running into problems.
>
> How should I do it?
>
> I tried running "debugserver localhost:42000" and then, on the lldb client:
>
> platform select (remote-macosx | remote-gdb-server?) + platform connect?
> platform select … + process connect?

The platform stuff is still a work in progress which we hope to really perfect over the next year. If you are doing Mac to Mac debugging the best thing to do right now is:

AFP mount the root drive on the other machine. For these examples lets suppose we have machine1 and machine2. So the flow would be:

- machine1: start debugserver:
machine1 % debugserver localhost:12345 /bin/ls

- machine2: mount the root drive from machine2 and launch lldb:
machine2 % ./lldb
(lldb) platform select remote-macosx --sysroot /Volumes/machine1
(lldb) process connect connect://machine1:12345

This should do it. Currently the platforms don't do any file copying from one to the other, so you will need a copy of all executables and shared libraries to exist within the "Volumes/machine1" directory. So if you are running "/bin/ls" it should be available through your mount at: "/Volumes/machine1/bin/ls". Likewise for all shared libraries.

The problem is: what can you do? In my testing I couldn't (with platform remote-macosx and sysroot=/) find out anything about the program. I could only do a process continue, and not much more. I couldn't set breakpoints, I couldn't see the source, etc. Is this simply not in place?

My problem with adding this is that AFAICT, I can't know the remote system path for the file currently being debugged, using the gdb remote protocol (if I could, the process could set the correct target when connecting to the debugserver). target create also doesn't allow me to say which program is being debugged because it wants a connected platform. target modules add will load information about the module, but not allow me to set breakpoints. Since we don't have a target, the MacOSX DYLD plugin won't get called when additional modules are loaded.

Since MacOSX is using the remote plugin for all debugging purposes it seems we only need to allow the MacOSX plugins to be used when using platform remote-macosx, as well as resolving the remote paths whenever asked. Is this right?

So, should we somehow get the path to the executable from the debugserver? Should we allow the user to do a target create … and use that file? Should 'process connect' receive an additional argument for the executable?

No, as above, we should create the target with the needed file, then connect. Eventually we need the platform to be able to allow us to request a remote file when we attach or launch, but that isn't there yet.

Greg

11

Hi,

12

Hi,

> One way to fix this is to allow 'target create' (or another command) to tell the debugger which executable file we're using. That way, we could make it the executable image and then call CompleteAttach (or redo some of the steps) in order to get everything working (including the DYLD plugin). Is this a good way to do that? Or do you prefer to just have lldb talk to itself (and lldb-platform)?

Exactly! You should be able to specify the local copy of the file you have. We will always check the UUIDs of the executable files you have loaded when dyld comes along. For instance, locally you have a binary "/tmp/a.out". Remotely this file is in "/usr/local/bin/a.out".

You can start lldb, set the platform, set the file and attach:

% lldb
(lldb) platform select ...
(lldb) target create /tmp/a.out
(lldb) process connect ....

Now when the dynamic loader plug-in gets info about a remote binary, it will say the path is at "/usr/local/bin/a.out", but we will notice that the UUID in the binary matches, so we don't care what the local path is.

LLDB currently really needs to have local copies of the files in order to debug. The architecture you select when you create the target really helps to specify which sets of plug-ins get loaded.

But you can't do that right now. As of now, if you didn't "platform connect", m_remote_platform_sp is NULL. That way, you'll just get an error when issuing the "target create" command, because you can't resolve the executable (see PlatformDarwin.cpp:83).

I can currently do this just fine:

(lldb) platform select remote-ios
  Platform: remote-ios
Connected: no
  SDK Path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2"
(lldb) target create a.out
Current executable set to 'a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libgcc_s.1.dylib
[ 3] /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/lib/libSystem.B.dylib
...

Is this just not working for remote-macosx?

I was thinking about adding the code to resolve the executable in relation to the platform's sysroot (I suppose I would just concatenate the directories and try to resolve the FileSpec). That way, we would be able to create a target before connecting.

It is already working, no??

13

Hi,

Yes, PlatformRemoteiOS overrides the ResolveExecutable method. My suggestion is to apply the following patch to PlatformDarwin or override that same method on PlatformMacOSX and check for that special case.

If this patch is applied, the PlatformRemoteiOS::ResolveExecutable override doesn’t seem to make sense anymore (modulus error messages). Please check if that is still needed (I can’t even test on iOS devices ;-)).

Regards,

Filipe

14

Was there a patch?

15

Yes, but it seems I didn’t include it.

Here goes.

Filipe

fix-remote-macosx-target-create.patch (999 Bytes)