Re: [Lldb-commits] [PATCH] D32087: Modify GDBRemoteCommunication::ScopedTimeout to not ever decrease a timeout

2017-04-18 Thread Pavel Labath via lldb-commits
0 means 0 here. For the time being, we don't have a way to specify infinite gdb timeout. On 15 April 2017 at 15:45, Zachary Turner wrote: > Does 0 mean infinite here? If so are the newly introduced semantics here > still correct? > On Sat, Apr 15, 2017 at 3:34 AM Pavel

[Lldb-commits] [PATCH] D32087: Modify GDBRemoteCommunication::ScopedTimeout to not ever decrease a timeout

2017-04-17 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL300455: Don't ever reduce the timeout of a packet, only increase it. (authored by gclayton). Changed prior to commit: https://reviews.llvm.org/D32087?vs=95314=95442#toc Repository: rL LLVM

Re: [Lldb-commits] [PATCH] D32087: Modify GDBRemoteCommunication::ScopedTimeout to not ever decrease a timeout

2017-04-15 Thread Zachary Turner via lldb-commits
Does 0 mean infinite here? If so are the newly introduced semantics here still correct? On Sat, Apr 15, 2017 at 3:34 AM Pavel Labath via Phabricator via lldb-commits wrote: > labath accepted this revision. > labath added a comment. > This revision is now accepted and

[Lldb-commits] [PATCH] D32087: Modify GDBRemoteCommunication::ScopedTimeout to not ever decrease a timeout

2017-04-15 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. looks good, thank you. https://reviews.llvm.org/D32087 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D32087: Modify GDBRemoteCommunication::ScopedTimeout to not ever decrease a timeout

2017-04-14 Thread Greg Clayton via Phabricator via lldb-commits
clayborg created this revision. We use GDBRemoteCommunication::ScopedTimeout in many places to change the packet timeout that is used for individual packets. If someone modifies the default timeout manually or the GDB remote server requests a longer timeout in a 'q' packet, then don't ever