Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Pavel Labath via lldb-dev]

On 27 November 2017 at 20:33, Christopher Book via lldb-dev
 wrote:
> Greetings, I've been using liblldb to remotely debug to a linux server with
> port forwarding.  To do this, I start lldb-server to with --listen
> specifying a localhost port, as well as with min-gdbserver-port and
> --max-gdbserver-port to specify a specific port for use by 'gdb remote'.
> Both ports are forwarded to the remote PC, where liblldb connects to
> localhost.
>
> This generally works fine, but there is a race condition.  When the client
> tells lldb-server to start gdb-remote, the port is returned to the client
> which may try to connect before the gdb-remote process is actually
> listening.
Are you sure this is what's happening? Looking at lldb-server source
code, I see that it starts listening on lldb-gdbserver.cpp:320
  error = acceptor_up->Listen(1);
  if (error.Fail()) {
fprintf(stderr, "failed to listen: %s\n", error.AsCString());
exit(1);
  }
and the port number is written out only later, on line 334:
  error = acceptor_up->Listen(1);
  if (error.Fail()) {
fprintf(stderr, "failed to listen: %s\n", error.AsCString());
exit(1);
  }

After listen returns the connection by your port forwarder should not
be rejected, and it can only connect once it knows the port to connect
to.


That's not to say that connecting through port forwarders is easy. For
android debugging, we also have to setup port forwarding with adb, and
we need to do some quite elaborate dances to make sure that the
connection is reliable and race free (see
PlatformAndroidRemoteGDBServer::MakeConnectURL) -- however this is to
resolve a different issue (allocating the port on the local side from
which to do the forwarding), which does not sound like the problem you
describe.


> I would like to submit a patch, but first check to see if this solution
> would be acceptable:
> - Include the handshake within the connection retry loop.
> - This means fully disconnecting the re-establishing the connection in the
> loop if the handshake fails.
> - Changing the timeout check to be based on a total absolute time instead of
> 50 iterations with a 100ms sleep.
>
> Thoughts?
>
> Alternatives could be:
> - Have lldb-server delay responding to the 'start gdb server' request until
> it could tell (somehow) that the process is listening.
> - A sleep of some kind on the client side after starting the server but
> before trying to connect.
>

The most port-forwarder-friendly solution (and one that I've been
wanting to implement for a while, but never got around to it) I can
think of is to not require a second port for the llgs connection. It
could work approximately like this:
- we add a new packet type to the lldb-server platform instance: (e.g.
qExecGDBServer)
- upon receiving this packet, the platform instance would exec the
gdb-server instance, and pass it the existing socket file descriptor
(via a command line argument or whatever)
- the gdb-server instance would start up with the connection primed
and ready, and would not need to do any listening and writing back the
port number, etc.
- the lldb client would end up with it's "platform" connection being
connected to llgs, and would have to create a new platform connection
(or it could create a scratch platform solely for the purpose of
exec()ing the llgs). Either way, the second connection would be to the
exact same address and port as the first one, so there should not be
any extra forwarding setup necessary.

The details of this will need to be thought through (e.g., who should
send the first packet after the exec()? how to detect an error? should
the connection start in no-ack mode?), but I don't think it should be
too complicated overall. And all port-forwarding users would benefit
from that (we could delete the android-specific code I mentioned, and
you could stop mucking with --max-gdbserver-port).

What do you think about that?

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

[lldb-dev] LLDB support for symbol files (PDB vs DWARF implementation)

[Daniel Olivier via lldb-dev]

Hi.

My goal is to process symbol files (i.e. PE-COFF/PDB, ELF/DWARF), and so I 
sought to examine how this is done in lldb. However, without first studying the 
code for an unreasonable amount of time, I just want to ask this simple 
question.

Consider the header files that pertain to symbol files in llvm (i.e. 
$LLVM_ROOT/include/llvm/DebugInfo) and lldb (i.e. 
$LLVM_ROOT/tools/lldb/source/Plugins/SymbolFile/).

For PDB support, I see only two classes (.cpp/.h file pairs, in 
$LLDB_ROOT/source/Plugins/SymbolFile/PDB), PDBASTParser and SymbolFilePDB, 
which appear to leverage the LLVM PDB implementation, and act as a facade to 
the LLVM implementation. This pattern doesn't repeat in the case of the DWARF 
format, where the file and class hierarchy appears duplicated, and yet are also 
quite different.

Its hard to describe the differences and similarities I see between the DWARF 
files, but so far, I can only guess that the differences are historical (forked 
and never re-merged), and that lldb only ever needed to read these files (the 
base LLVM implementation being more complete, in order to be able to generate 
them in the first place and merge or manipulate them once they are created).

Can anyone briefly explain the architectural choices made here?

Thanks

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

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Adrian Prantl via lldb-dev]

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 
>  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 
> process attach -P gdb-remote --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  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  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
> 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

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Greg Clayton via lldb-dev]

> On Nov 28, 2017, at 2:25 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 27 November 2017 at 20:33, Christopher Book via lldb-dev
>  wrote:
>> Greetings, I've been using liblldb to remotely debug to a linux server with
>> port forwarding.  To do this, I start lldb-server to with --listen
>> specifying a localhost port, as well as with min-gdbserver-port and
>> --max-gdbserver-port to specify a specific port for use by 'gdb remote'.
>> Both ports are forwarded to the remote PC, where liblldb connects to
>> localhost.
>> 
>> This generally works fine, but there is a race condition.  When the client
>> tells lldb-server to start gdb-remote, the port is returned to the client
>> which may try to connect before the gdb-remote process is actually
>> listening.
> Are you sure this is what's happening? Looking at lldb-server source
> code, I see that it starts listening on lldb-gdbserver.cpp:320
>  error = acceptor_up->Listen(1);
>  if (error.Fail()) {
>fprintf(stderr, "failed to listen: %s\n", error.AsCString());
>exit(1);
>  }
> and the port number is written out only later, on line 334:
>  error = acceptor_up->Listen(1);
>  if (error.Fail()) {
>fprintf(stderr, "failed to listen: %s\n", error.AsCString());
>exit(1);
>  }
> 
> After listen returns the connection by your port forwarder should not
> be rejected, and it can only connect once it knows the port to connect
> to.
> 
> 
> That's not to say that connecting through port forwarders is easy. For
> android debugging, we also have to setup port forwarding with adb, and
> we need to do some quite elaborate dances to make sure that the
> connection is reliable and race free (see
> PlatformAndroidRemoteGDBServer::MakeConnectURL) -- however this is to
> resolve a different issue (allocating the port on the local side from
> which to do the forwarding), which does not sound like the problem you
> describe.
> 
> 
>> I would like to submit a patch, but first check to see if this solution
>> would be acceptable:
>> - Include the handshake within the connection retry loop.
>> - This means fully disconnecting the re-establishing the connection in the
>> loop if the handshake fails.
>> - Changing the timeout check to be based on a total absolute time instead of
>> 50 iterations with a 100ms sleep.
>> 
>> Thoughts?
>> 
>> Alternatives could be:
>> - Have lldb-server delay responding to the 'start gdb server' request until
>> it could tell (somehow) that the process is listening.
>> - A sleep of some kind on the client side after starting the server but
>> before trying to connect.
>> 
> 
> The most port-forwarder-friendly solution (and one that I've been
> wanting to implement for a while, but never got around to it) I can
> think of is to not require a second port for the llgs connection. It
> could work approximately like this:
> - we add a new packet type to the lldb-server platform instance: (e.g.
> qExecGDBServer)
> - upon receiving this packet, the platform instance would exec the
> gdb-server instance, and pass it the existing socket file descriptor
> (via a command line argument or whatever)
> - the gdb-server instance would start up with the connection primed
> and ready, and would not need to do any listening and writing back the
> port number, etc.
> - the lldb client would end up with it's "platform" connection being
> connected to llgs, and would have to create a new platform connection
> (or it could create a scratch platform solely for the purpose of
> exec()ing the llgs). Either way, the second connection would be to the
> exact same address and port as the first one, so there should not be
> any extra forwarding setup necessary.

I am not a fan of losing the lldb-server platform connection by turning it into 
the GDB server connection. It means you need to connect and launch each time 
instead of connect once to the platform and then launch N times.

> 
> The details of this will need to be thought through (e.g., who should
> send the first packet after the exec()? how to detect an error? should
> the connection start in no-ack mode?), but I don't think it should be
> too complicated overall. And all port-forwarding users would benefit
> from that (we could delete the android-specific code I mentioned, and
> you could stop mucking with --max-gdbserver-port).
> 
> What do you think about that?

Since the port forwarding and the lldb-server need to be in cahoots, maybe an 
extra argument is added to the "lldb-server platform" invocation that tell us 
we are using port forwarding and we do something special in the "lldb-server 
platform" binary to bullet proof the connection?

Greg

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

Re: [lldb-dev] LLDB support for symbol files (PDB vs DWARF implementation)

[Greg Clayton via lldb-dev]

> On Nov 28, 2017, at 6:49 AM, Daniel Olivier via lldb-dev 
>  wrote:
> 
> Hi.
> 
> My goal is to process symbol files (i.e. PE-COFF/PDB, ELF/DWARF), and so I 
> sought to examine how this is done in lldb. However, without first studying 
> the code for an unreasonable amount of time, I just want to ask this simple 
> question.
> 
> Consider the header files that pertain to symbol files in llvm (i.e. 
> $LLVM_ROOT/include/llvm/DebugInfo) and lldb (i.e. 
> $LLVM_ROOT/tools/lldb/source/Plugins/SymbolFile/).
> 
> For PDB support, I see only two classes (.cpp/.h file pairs, in 
> $LLDB_ROOT/source/Plugins/SymbolFile/PDB), PDBASTParser and SymbolFilePDB, 
> which appear to leverage the LLVM PDB implementation, and act as a facade to 
> the LLVM implementation. This pattern doesn't repeat in the case of the DWARF 
> format, where the file and class hierarchy appears duplicated, and yet are 
> also quite different. 
> 
> Its hard to describe the differences and similarities I see between the DWARF 
> files, but so far, I can only guess that the differences are historical 
> (forked and never re-merged), and that lldb only ever needed to read these 
> files (the base LLVM implementation being more complete, in order to be able 
> to generate them in the first place and merge or manipulate them once they 
> are created).


> Can anyone briefly explain the architectural choices made here?

LLMV's DWARF parser was born as a copy of the LLDB DWARF parser at the time and 
the person that did the port never attempted to switch LLDB to using the LLVM 
version as the only reason he added it was to be able to extract line table 
information. The LLMV DWARF parser has grown a lot over the years. Someone 
could take the time to switch LLDB over to use the LLVM DWARF parser, but that 
is a lot of work that will likely introduce bugs in the short term, though this 
would be valuable to do. I worked on the LLMV DWARF parser in an effort to make 
that happen last year, so the LLVM DWARF parser has everything that LLDB needs 
in order to switch, except someone that has the time to do this work.

LLDB provides an object file (ELF, COFF, MACHO) and debug info (DWARF, PDB) 
agnostic representation of debug info that can represent everything in these 
files. We have plugins for DWARF and PDB that convert those formats into the 
LLDB format. We do so lazily by parsing only what we need when we need it. 
Another step that the symbol file plug-ins in LLDB do is to convert any types 
in the debug info into clang::ASTContext types so we can use clang to run 
expressions on the debug info which has been converted back into clang AST 
types.

So if you are looking to process symbol files, you could just use LLDB 
(LLDB.framework on Mac or liblldb.so on other systems). We have a public API 
that is stable and that entire API is available through python in case you need 
to script any solutions. 

Can you elaborate on what you are wanting to do with your parsing of the 
object/debug info files?

Greg


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

Re: [lldb-dev] LLDB support for symbol files (PDB vs DWARF implementation)

[Zachary Turner via lldb-dev]

On Tue, Nov 28, 2017 at 6:49 AM Daniel Olivier via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi.
>
> My goal is to process symbol files (i.e. PE-COFF/PDB, ELF/DWARF), and so I
> sought to examine how this is done in lldb. However, without first studying
> the code for an unreasonable amount of time, I just want to ask this simple
> question.
>
> Consider the header files that pertain to symbol files in llvm (i.e.
> $LLVM_ROOT/include/llvm/DebugInfo) and lldb (i.e.
> $LLVM_ROOT/tools/lldb/source/Plugins/SymbolFile/).
>
> For PDB support, I see only two classes (.cpp/.h file pairs, in
> $LLDB_ROOT/source/Plugins/SymbolFile/PDB), PDBASTParser and SymbolFilePDB,
> which appear to leverage the LLVM PDB implementation, and act as a facade
> to the LLVM implementation. This pattern doesn't repeat in the case of the
> DWARF format, where the file and class hierarchy appears duplicated, and
> yet are also quite different.
>
> Its hard to describe the differences and similarities I see between the
> DWARF files, but so far, I can only guess that the differences are
> historical (forked and never re-merged), and that lldb only ever needed to
> read these files (the base LLVM implementation being more complete, in
> order to be able to generate them in the first place and merge or
> manipulate them once they are created).
>
> Can anyone briefly explain the architectural choices made here?
>

Your guesses are pretty much accurate.

By the way, I'll point out that the PDB parsing code in LLDB doesn't
technically use the PDB parsing code in LLVM.  At least not in the way you
might expect.

This code was added to LLDB before LLVM supported native PDB reading and
writing.  To make this possible, and planning for the case in the future
where LLVM could support native PDB, an interface was added to LLVM that
provided access to PDB data, but could be implemented in different ways.

Since there was no native PDB support in LLVM at the time, the natural path
just to get something to work in LLDB was to provide an implementation
based ont he Windows DIA SDK, and this is what was done and that is the
implementation that LLDB uses today.

Later, we added all the native PDB support to LLVM, but it was done at a
lower level than this interface abstraction, and the implementation to make
use of this native PDB reading code from LLVM is incomplete.  Work has
started on it, and then later stalled as priorities shifted around.

So, if you want to process PDB files using LLDB, currently you will need to
be on Windows.  If you want o make it work on non-Windows, the first step
will be completing the implementation of this interface in LLVM.  After
that it should be a matter of changing 1 or 2 lines of code in LLDB to swap
the implementation.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Greg Clayton via lldb-dev]

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 



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 % 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"
PIDPARENT 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 
>  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 
>> 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 
>> process attach -P gdb-remote --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  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  LLDB will att

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Jim Ingham via lldb-dev]

Hey, Greg,

If you have a moment, could you add what isn't already there of this useful 
info to http://lldb.llvm.org/remote.html?  The correct answer to this question 
should be "read http://lldb.llvm.org/remote.html"; but that doesn't seem as 
immediately useful as your description.

Jim


> On Nov 28, 2017, at 11:02 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> 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
> 
> 
> 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% 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"
> PIDPARENT 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 
>>  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 
>>>  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 
>>> process attach -P gdb-remote --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 

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Greg Clayton via lldb-dev]

I will update the remote.html web page with any info that is missing! I was 
about to go write the web page... Didn't realize we had one.

> On Nov 28, 2017, at 11:08 AM, Jim Ingham  wrote:
> 
> Hey, Greg,
> 
> If you have a moment, could you add what isn't already there of this useful 
> info to http://lldb.llvm.org/remote.html?  The correct answer to this 
> question should be "read http://lldb.llvm.org/remote.html"; but that doesn't 
> seem as immediately useful as your description.
> 
> Jim
> 
> 
>> On Nov 28, 2017, at 11:02 AM, Greg Clayton via lldb-dev 
>>  wrote:
>> 
>> 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
>> 
>> 
>> 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% 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"
>> PIDPARENT 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 
>>>  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 
  wrote:
 
 I'm trying to remotely launch and debug a new process with lldb without 
 much success.
 
 Attaching to an already launched p

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Jim Ingham via lldb-dev]

Thanks!

Jim


> On Nov 28, 2017, at 11:16 AM, Greg Clayton  wrote:
> 
> I will update the remote.html web page with any info that is missing! I was 
> about to go write the web page... Didn't realize we had one.
> 
>> On Nov 28, 2017, at 11:08 AM, Jim Ingham  wrote:
>> 
>> Hey, Greg,
>> 
>> If you have a moment, could you add what isn't already there of this useful 
>> info to http://lldb.llvm.org/remote.html?  The correct answer to this 
>> question should be "read http://lldb.llvm.org/remote.html"; but that doesn't 
>> seem as immediately useful as your description.
>> 
>> Jim
>> 
>> 
>>> On Nov 28, 2017, at 11:02 AM, Greg Clayton via lldb-dev 
>>>  wrote:
>>> 
>>> 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
>>> 
>>> 
>>> 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% 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"
>>> PIDPARENT 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 
  wrote:
 
 I would recommend asking this on the lldb mailing list instead.
 
 -- adrian
 
> On Nov 26, 20

Re: [lldb-dev] [llvm-dev] Remotely launching a new process with LLDB

[Greg Clayton via lldb-dev]

svn commit remote.html 
Sendingremote.html
Transmitting file data .done
Committing transaction...
Committed revision 319213.

Please read through these changes at:

http://lldb.llvm.org/remote.html 

and see if there are any mistakes or need for clarification.

Greg

> On Nov 28, 2017, at 11:17 AM, Jim Ingham  wrote:
> 
> Thanks!
> 
> Jim
> 
> 
>> On Nov 28, 2017, at 11:16 AM, Greg Clayton  wrote:
>> 
>> I will update the remote.html web page with any info that is missing! I was 
>> about to go write the web page... Didn't realize we had one.
>> 
>>> On Nov 28, 2017, at 11:08 AM, Jim Ingham  wrote:
>>> 
>>> Hey, Greg,
>>> 
>>> If you have a moment, could you add what isn't already there of this useful 
>>> info to http://lldb.llvm.org/remote.html?  The correct answer to this 
>>> question should be "read http://lldb.llvm.org/remote.html"; but that doesn't 
>>> seem as immediately useful as your description.
>>> 
>>> Jim
>>> 
>>> 
 On Nov 28, 2017, at 11:02 AM, Greg Clayton via lldb-dev 
  wrote:
 
 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
 
 
 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% 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"
 PIDPARENT USER   TRIPLE   NAME
 == == ==  
 
 68881  96266  (null) x86_64-apple-macosx  lldb-server
 68639  90652 x86_64-apple-macos

Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding

[Christopher Book via lldb-dev]

Hi Pavel, I think you are on the right track in that it already does seem
to wait for the gdbserver to be up using a pipe.

In StartDebugserverProcess it seems like there is a pipe created to tell
when the server is running.  Here is a comment:

// socket_pipe is used by debug server to communicate back either
// TCP port or domain socket name which it listens on.
// The second purpose of the pipe to serve as a synchronization point -
// once data is written to the pipe, debug server is up and running.

However, it looks like specifying --min-gdbserver-port and
--max-gdbserver-port cause the pipe to not be used for some reason.

Here is the gdbserver invocation when I don't specify the gdb min and max
port:
> lldb-server gdbserver tcp://:0 --native-regs --pipe 6

And here is the gdbserver invocation when I do specify the gdb port:
> lldb-server gdbserver tcp://: --native-regs

Its not obvious to me from looking at the code why this is being skipped.
But I will debug further why this argument is not used in this case.

Thanks,
Chris

On Tue, Nov 28, 2017 at 5:25 AM Pavel Labath  wrote:

> On 27 November 2017 at 20:33, Christopher Book via lldb-dev
>  wrote:
> > Greetings, I've been using liblldb to remotely debug to a linux server
> with
> > port forwarding.  To do this, I start lldb-server to with --listen
> > specifying a localhost port, as well as with min-gdbserver-port and
> > --max-gdbserver-port to specify a specific port for use by 'gdb remote'.
> > Both ports are forwarded to the remote PC, where liblldb connects to
> > localhost.
> >
> > This generally works fine, but there is a race condition.  When the
> client
> > tells lldb-server to start gdb-remote, the port is returned to the client
> > which may try to connect before the gdb-remote process is actually
> > listening.
> Are you sure this is what's happening? Looking at lldb-server source
> code, I see that it starts listening on lldb-gdbserver.cpp:320
>   error = acceptor_up->Listen(1);
>   if (error.Fail()) {
> fprintf(stderr, "failed to listen: %s\n", error.AsCString());
> exit(1);
>   }
> and the port number is written out only later, on line 334:
>   error = acceptor_up->Listen(1);
>   if (error.Fail()) {
> fprintf(stderr, "failed to listen: %s\n", error.AsCString());
> exit(1);
>   }
>
> After listen returns the connection by your port forwarder should not
> be rejected, and it can only connect once it knows the port to connect
> to.
>
>
> That's not to say that connecting through port forwarders is easy. For
> android debugging, we also have to setup port forwarding with adb, and
> we need to do some quite elaborate dances to make sure that the
> connection is reliable and race free (see
> PlatformAndroidRemoteGDBServer::MakeConnectURL) -- however this is to
> resolve a different issue (allocating the port on the local side from
> which to do the forwarding), which does not sound like the problem you
> describe.
>
>
> > I would like to submit a patch, but first check to see if this solution
> > would be acceptable:
> > - Include the handshake within the connection retry loop.
> > - This means fully disconnecting the re-establishing the connection in
> the
> > loop if the handshake fails.
> > - Changing the timeout check to be based on a total absolute time
> instead of
> > 50 iterations with a 100ms sleep.
> >
> > Thoughts?
> >
> > Alternatives could be:
> > - Have lldb-server delay responding to the 'start gdb server' request
> until
> > it could tell (somehow) that the process is listening.
> > - A sleep of some kind on the client side after starting the server but
> > before trying to connect.
> >
>
> The most port-forwarder-friendly solution (and one that I've been
> wanting to implement for a while, but never got around to it) I can
> think of is to not require a second port for the llgs connection. It
> could work approximately like this:
> - we add a new packet type to the lldb-server platform instance: (e.g.
> qExecGDBServer)
> - upon receiving this packet, the platform instance would exec the
> gdb-server instance, and pass it the existing socket file descriptor
> (via a command line argument or whatever)
> - the gdb-server instance would start up with the connection primed
> and ready, and would not need to do any listening and writing back the
> port number, etc.
> - the lldb client would end up with it's "platform" connection being
> connected to llgs, and would have to create a new platform connection
> (or it could create a scratch platform solely for the purpose of
> exec()ing the llgs). Either way, the second connection would be to the
> exact same address and port as the first one, so there should not be
> any extra forwarding setup necessary.
>
> The details of this will need to be thought through (e.g., who should
> send the first packet after the exec()? how to detect an error? should
> the connection start in no-ack mode?), but I don't thin