Re: [lldb-dev] race condition using gdb-remote over ssh port forwarding
On 28 November 2017 at 20:54, Christopher Book wrote: > 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. > Aha, interesting. That would explain why there is a race. We should add the pipe synchronization even in case we know what is the port going to be (though I still like the "exec" idea). ___ 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
On 28 November 2017 at 18:31, Greg Clayton wrote: > >> On Nov 28, 2017, at 2:25 AM, Pavel Labath via lldb-dev >> wrote: >> 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 overall number of connections stays the same. The difference is that instead of 1 connection to the platform and N gdb-server connections, you will have N+1 platform connections (of those, N will be later transformed into an llgs connection). The only thing that changes from the client side is the gdb-server startup sequence. Instead of: - send qSpawnGDBServer - read port - construct url from port // This is where things break down. With NAT, we have no way do know whether the port we should use is the same as the other side uses. - connect - talk to gdb-server we do this: - connect to platform (using the already-known url) - send qExecGdbServer - talk to gdb-server > >> >> 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? I don't think there is any single thing that can be done to "bullet proof" the connection, as the exact course of action will depend on the type of forwarding used. And it certainly can't be done on the server, as the server generally knows nothing about the port forwarding. The only one who can possibly know about the port forwarding is the client, but even this is not always the case (it could be your home router doing a NAT). The only bullet proof way to get rid of these kinds of issues is to avoid the FTP-like two connection setup (the separate data and control connections is why every NAT needs to handle FTP protocol specially, and every protocol since then has avoided this kind of setup, as it was causing too many issues). ___ 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
I made a mistake and was not looking at the latest source. Looks like this exact issue was already discovered and fixed: https://reviews.llvm.org/D30255 I'm using 4.0.1, so it appears I need to upgrade. Chris On Wed, Nov 29, 2017 at 5:45 AM Pavel Labath wrote: > On 28 November 2017 at 20:54, Christopher Book wrote: > > 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. > > > > Aha, interesting. That would explain why there is a race. We should > add the pipe synchronization even in case we know what is the port > going to be (though I still like the "exec" idea). > ___ 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
Great! Please let us know what works for you and any features you might want
out of LLDB's remote debugging as you use it day to day.
Greg Clayton
> On Nov 29, 2017, at 12:57 AM, Lior Halphon wrote:
>
> Thank you all very much! The script lines (especially "script
> m.SetPlatformFileSpec("/bin/a.out")") were exactly what I was missing. I
> ended up patching LLDB locally in order to debug, but now I can use Apple's
> official LLDB builds.
>> On 28 Nov 2017, at 22:06, Greg Clayton > > wrote:
>>
>> 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
>> mailto:lldb-dev@lists.llvm.org>> 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
