[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-10 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. In D83446#2143464 , @labath wrote: > In D83446#2142564 , @JDevlieghere > wrote: > > > Seems like my thoughts got lost a bit with all the inline replies: we can > > solve this particular is

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-10 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. In D83446#2142564 , @JDevlieghere wrote: > Seems like my thoughts got lost a bit with all the inline replies: we can > solve this particular issue by making `process connect` block in synchronous > mode. The fact that that's not

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. I want to be careful not to conflate lldb's general event behavior with the way the command interpreter happens to run things. For instance, there's no requirement that the debugger be the event listener for processes. You can have a listener per process under the same

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment. Seems like my thoughts got lost a bit with all the inline replies: we can solve this particular issue by making `process connect` block in synchronous mode. The fact that that's not happening today is a bug beyond the reproducers. I don't think we should change the

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. In D83446#2142350 , @JDevlieghere wrote: > In D83446#2142301 , @jingham wrote: > > > I think the proper way to gate this sort of "race" is to use the process > > state. If the current pro

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment. In D83446#2142473 , @labath wrote: > In D83446#2142030 , @JDevlieghere > wrote: > > > Agreed. I believe at some point (long before I started working on LLDB) all > > the GDB communica

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. In D83446#2142030 , @JDevlieghere wrote: > In D83446#2141713 , @labath wrote: > > > I'm wondering if this problem does not go beyond reproducers... The fact > > that we can have two threads

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment. In D83446#2142301 , @jingham wrote: > I think the proper way to gate this sort of "race" is to use the process > state. If the current process state is "stopped" then that means we're done > with the stop processing and rea

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. I think the proper way to gate this sort of "race" is to use the process state. If the current process state is "stopped" then that means we're done with the stop processing and ready to allow commands that require the process to be stopped. When I originally did this

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment. In D83446#2141713 , @labath wrote: > Well, this is an interesting problem... IIUC, what's happening is that the > printing of the "stop reason" in the "event handler thread" is generating > some packets (to fetch the stop re

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a reviewer: jingham. labath added a comment. Well, this is an interesting problem... IIUC, what's happening is that the printing of the "stop reason" in the "event handler thread" is generating some packets (to fetch the stop reason), and then the "cont" command produces some (c) t

[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

2020-07-08 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision. JDevlieghere added reviewers: labath, friss. Herald added a subscriber: abidh. Add synchronization for asynchronous events. This fixes an un expected packet during replay when an asynchronous event triggers a GDB packet. Consider the following example: $ ./