lldb-server can be launched in two ways:
1 - platform connection mode
2 - debug a single process mode

LLDB has two ways to connect to a remote process:
1 - you launch the GDB server yourself and attach to it
2 - you launch lldb-server in platform mode, connect to the platform, and then 
just debug like you normally would on a local machine.

When you launch the GDB server yourself as mentioned in step 1 above, you can 
do:

remote.foo.com% lldb-server gdbserver 1234 -- /bin/ls -lAF

Then attach to it yourself:

local.foo.com% lldb
(lldb) process connect connect://remote.foo.com:1234 
<connect://remote.foo.com:1234>


When you want an lldb-server to do the work of startup on the GDB server for 
you:

remote.foo.com% lldb-server platform --server --listen 1234

Then you select the remote platform and connect to it with LLDB:

local.foo.com <http://local.foo.com/>% lldb
(lldb) platform select remote-macosx 
  Platform: remote-macosx
 Connected: no
(lldb) platform connect connect://localhost:1234
  Platform: remote-macosx
    Triple: x86_64-apple-macosx
OS Version: 10.12.6 (16G1036)
    Kernel: Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; 
root:xnu-3789.71.6~1/RELEASE_X86_64
  Hostname: gclayton-pro
 Connected: yes
WorkingDir: /Users/gclayton

Now LLDB has a "platform" connection to the remote machine that can start up 
the GDB server for you. Also note that the platform states what its working 
directory is (which defaults to the directory it was launched in).

If you want to launch a locally built executable on the remote side, now you 
can do:

(lldb) file a.out
(lldb) run

This will cause LLDB to create a target with the "a.out" executable that you 
cross built. Then you "run" and this will cause LLDB to upload "a.out" to the 
platform's current working directory only if the file has changed. The platform 
connection allows us to transfer files, but also allows us to get the MD5 
checksum of the file on the other end in the current working directory and only 
upload the file if it has changed. If you don't want the "a.out" executable to 
be uploaded to the current platform working directory you can do to specify 
where the executable will be uploaded to:

(lldb) file /local/path/to/a.out
# Get the lldb.SBModule for "/local/path/to/a.out" in the local variable named 
"m":
(lldb) script m = lldb.target.module['a.out']
# Set the platform path for the executable to "/bin/a.out":
(lldb) script m.SetPlatformFileSpec("/bin/a.out")
(lldb) run

Now when you run your program, the program will be uploaded to "/bin/a.out" 
instead of the the current working directory of the platform.

You can also change the platform working directory if you are connected to the 
platform

(lldb) platform settings -w /tmp

And you can verify it worked using "platform status":

(lldb) platform status
  Platform: remote-macosx
    Triple: x86_64-apple-macosx
OS Version: 10.12.6 (16G1036)
    Kernel: Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; 
root:xnu-3789.71.6~1/RELEASE_X86_64
  Hostname: gclayton-pro
 Connected: yes
WorkingDir: /private/tmp


If you want to attach to a remote process, you can list the processes if you 
are connected:

(lldb) platform process list
223 matching processes were found on "remote-macosx"
PID    PARENT USER       TRIPLE                   NAME
====== ====== ========== ======================== ============================
68881  96266  (null)     x86_64-apple-macosx      lldb-server
68639  90652             x86_64-apple-macosx      lldb
67830  1                 x86_64-apple-macosx      helpd
67737  1                 x86_64-apple-macosx      com.apple.iCloudHelper

...

Then attach:

(lldb) attach 68639

Let me know if you have any questions.

Greg Clayton


> On Nov 28, 2017, at 9:29 AM, Adrian Prantl via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> I would recommend asking this on the lldb mailing list instead.
> 
> -- adrian
> 
>> On Nov 26, 2017, at 8:30 AM, Lior Halphon via llvm-dev 
>> <llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote:
>> 
>> I'm trying to remotely launch and debug a new process with lldb without much 
>> success.
>> 
>> Attaching to an already launched process works well by running these 
>> commands:
>> 
>> process connect <url>
>> process attach -P gdb-remote --pid <pid>
>> But if I want debugserver to launch the executable by itself I'm running 
>> into troubles. Especially, I have no clue what arguments should I pass to 
>> target
>>  create.
>> 
>> According to this page <https://lldb.llvm.org/remote.html> LLDB "will 
>> transparently take care of [..] downloading the executable in order to be 
>> able to debug", yet target
>>  create seem to always require a local file. If I specify the remote file 
>> via -r I get either unable
>>  to open target file or remote
>>  --> local transfer without local path is not implemented yet errors. If I 
>> set the target to a local file (such as a local copy of the remote's loader 
>> executable) without using -r, then attempt to run process
>>  launch -p gdb-remote -s <remote path> LLDB will attempt running the local 
>> path on the remote machine and fail.
>> 
>> What are the correct commands I need to use in order to launch a remote 
>> process?
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to