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,
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 seco
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
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 communi
> 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
>> spe
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-gd
> On Nov 27, 2017, at 3:50 PM, Christopher Book wrote:
>
> I have been using both a custom port-forwarding program as well as OpenSSH.
> The custom solution is a bit slower because it goes through a proxy, so the
> problem doesn't manifest. I've been trying to switch to OpenSSH which is
> f
I have been using both a custom port-forwarding program as well as
OpenSSH. The custom solution is a bit slower because it goes through a
proxy, so the problem doesn't manifest. I've been trying to switch to
OpenSSH which is fast enough to consistent hit the race condition.
I would expect other
On Mon, 27 Nov 2017 21:33:04 +0100, Christopher Book via lldb-dev wrote:
> Thoughts?
Not sure if it is applicable in this case but GDB has this feature:
https://sourceware.org/gdb/onlinedocs/gdb/Server.html#Running-gdbserver
(gdb) target remote | ssh -T hostname gdbserver - hello
When I wrote the code I was assuming that when the platform lldb-server
responds with the port that the gdb-remote would be ready to receive packets
right away, so I can see how and why this is happening. Seems like we have the
retry stuff under control when we don't get a connection right away,
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
11 matches
Mail list logo
